Course: Database Management System

(313302)

Unit 2 : Relational Data Model

Instructor
Prof. S.P.Chivate
K. K. Wagh Polytechnic, Nashik
 Course Outcome

After completing this course a learner will able to,

Course Outcome:
CO-2: Design the database for given problem.

Unit Outcomes:
TLO 2.2: State types of keys with example
 Relational Structures
1. Entity:
• An entity is a “thing” or “object” in the real world.
• An entity contains attributes, which describe that entity.
• So anything about which we store information is called an entity.
• For example: A student, An employee, or bank a/c, etc. all are entities.
 Relational Structures
2. Domain:
- A domain is the set of permitted values for one or more attributes.
- It defines the potential values that an attribute may hold.
- For e.g. If the age of the student in class is between 15 and 20, then we can
define a set of values for the age attribute of student as the set of integers
between 15 and 20.
3. Attribute:
- An attribute is a named column of a relation.
- For e.g. Student table has stud_id, Stud_name, Marks as attributes
 Relational Structures
4. Tuple:
- Tuple can also be called as record.
- Record can be defined as any row of a table.
- For e.g. data of one student in one row in student table is tuple.
5. Relation:
- A relation is a table with columns and rows.
- Tables are used to hold information about the objects to be represented in
the database.
Relational Structures
 DBMS Keys
- A DBMS key is an attribute or a set of attributes which help you uniquely identify a record
or row of data in a table.

- Reasons for using SQL keys in the DBMS system:

• Keys help to identify any row of data in a table. In a real-world application, a
table could contain thousands of records. Moreover, the records could be
duplicated. Keys ensure that you can uniquely identify a table record despite
these challenges.
• Allows you to establish a relationship and identify the relation between tables.
For example, ID is used as a key in the Student table because it is unique for each
student. In the PERSON table, passport_number, license_number, SSN are keys since they are
unique for each person.
 DBMS Keys

- Different Types of Keys in the Relational Model:

i) Primary Key

ii) Candidate Key

iii) Super Key

iv) Foreign Key

1. Primary Key
- PRIMARY KEY in DBMS is a attribute or group of attributes (means column or
group of columns) in a table that uniquely identify every row in the table.
- The Primary Key can’t be a duplicate means the same value can’t appear more
than once in the table.
- A table cannot have more than one primary key.
- It must for every row to have a primary key value.
- The primary key field cannot be null.
- The value in a primary key column can never be modified or updated if any
foreign key refers to that primary key.
Example of Primary Key
2. Candidate Key
- CANDIDATE KEY in SQL is a set of attributes that uniquely identify
tuples(rows) in a table.
- Except for the primary key, the remaining attributes are considered a
candidate key.
- The candidate keys are as strong as the primary key.
- The Primary key should be selected from the candidate keys.
- Every table must have at least a single candidate key.
- A table can have multiple candidate keys but only a single primary key.
- It must contain unique values.
- Candidate key in SQL may have multiple attributes.
- Must not contain null values.
Example of Candidate Key
Example of Candidate Key
 3. Super Key
- Super Key is defined as a set of attributes within a table that can uniquely
identify each record within a table.
- Super Key is a superset of Candidate key.
- In the following table, super key would include student_id, (student_id, name),
phone.
4. Foreign Key
Example of Foreign Key
•Every employee works in a specific department in a company, and employee and
department are two different entities. So we can't store the department's information
in the employee table. That's why we link these two tables through the primary key of
one table.
•We add the primary key of the DEPARTMENT table, Department_Id, as a new
attribute in the EMPLOYEE table.
 Data Constraints
Data Integrity :-
- Data Integrity refers to the accuracy and consistency of data.
- When creating databases, attention needs to be given to data integrity and how
to maintain it. A good database will enforce data integrity whenever possible.
- For example, a user could accidentally try to enter a phone number into a date
field. If the system enforces data integrity, it will prevent the user from making
these mistakes.
 Data Constraints

Constraints :-
- Constraints are the rules that we can apply on the type of data in a table.
- Constraints in SQL means we are applying certain conditions or restrictions on
the database.
- This further means that before inserting data into the database, we are checking
for some conditions.
- If the condition we have applied to the database holds true for the data which is
to be inserted, then only the data will be inserted into the database tables.
 Data Constraints
Integrity Constraints :-
- These are a set of rules.
- They ensure that when the authorized users modify the database they do not
disturb the data consistency.
- These are introduced while designing the database schema.
- The constraints are specified within the DDL commands like ‘create table’ and
‘alter table’ command.
- Types of Relational Integrity Constraints are as follows:
1. Domain constraints
2. Entity integrity constraints
3. Referential Integrity Constraints
 Data Constraints
1. Domain constraints :-
- Domain constraint defines the domain or 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.
- There are 2 constraints which we can study under domain constraint.
i) Not null constraint
ii) Check clause constraint
 1. Domain constraints
i. Not Null constraints
- By default, a column can hold NULL values.
- The NOT NULL constraint enforces a column to NOT accept NULL values.
- This enforces a field to always contain a value, which means that you cannot insert a new
record, or update a record without adding a value in the field.
- For example: in student database, every student must have an associated student name.
- Let us see how do we specify an attribute to be not null.
create table Student
(Student_id varchar (5) ,
name varchar (20) not null,
dept_name varchar (20));
 1. Domain Constraints
ii. Check Constraint
- Defines a condition that each row must satisfy.
- Used to restrict the value of a column between ranges.
- It is like condition checking before saving data into a column.
- The check constraint ensures that when a new tuple is inserted in relation it must satisfy
the condition specified in the check clause.
- For example :
Create table student (
Roll_no number(2) not null CHECK (Roll_no>0),
Name varchar(50) not null);
- The above example creates a CHECK constraint on the Roll_no column.
- The CHECK constraint specifies that the column Roll_no must only include integers
greater than 0.
 2. Entity integrity constraints
i. Primary Key Constraints

- It uniquely identifies each record in a database table.

- When this constraint is associated with the column of a table
i) It will not allow NULL values into the column.
ii) It will maintain unique values as part of the table.
- We can add only one Primary Key constraint on a table.
- We can say that a Primary Key constraint is a combination of Unique and NOT NULL
constraints
 2. Entity integrity constraints
- Primary Key example:
CREATE TABLE EMPLOYEE (
EMP_ID number(4) PRIMARY KEY,
EMP_NAME varchar(30),
SALARY Number(5) );
- The above SQL creates a PRIMARY KEY on the “EMP_ID” column when the “EMPLOYEE"
table is created.
 2. Entity integrity constraints
ii. Unique Key Constraint

- The UNIQUE key constraint uniquely identifies each record in a database table.
- UNIQUE key constraint ensures that a field or column will only have unique values.
- It is used to prevent duplicate values in a column or group.
- It allows null values.
- The unique key and primary key both provide a guarantee for uniqueness for a column or a
set of columns.
- There may be many unique key constraints for one table, but only one PRIMARY KEY
constraint for one table.
 2. Entity integrity constraints
-Unique Key Example

CREATE TABLE student (

Roll_no number(3) NOT NULL UNIQUE,
Seat_no number(6) UNIQUE,
Name varchar(255) NOT NULL,
Marks Number(5,2),
City varchar(255) );

- The above SQL creates a UNIQUE constraint on the "Roll_no" and ‘‘Seat_no ‘‘
column when the "student" table is created.
 3. Referential Integrity constraint
Referential Integrity constraint
- Referential Integrity Constraint is also known as foreign key constraint.
- It is defined between two tables to maintain the consistency among tuples in
the two relations.
- It is used to establish parent child relationship between two tables having a
common column.
- It states that if there is a foreign key in one table, it should match with
primary key from other table.
- Primary key is defined in parent table. Parent table is also called as
referenced table.
- Foreign key is defined in child table.
 3. Referential Integrity constraint
Referential Integrity Example
Dept

• Dept (Dept_No, DName, LOC)

• Emp(Emp_No,Ename,Job,Sal,Dept_No)
• In table Dept, Dept_No is a primary key containing unique values for deptnos.
• To set the relationship between these two tables , we can define Emp.Dept_No
as a foreign key.
 3. Referential Integrity constraint
Referential Integrity
Example

• Create table Dept ( Dept_No number(5) primary key, DName varchar(20),

LOC varchar(10) );

• Create table Emp ( Emp_No number(4), Ename varchar2(25), Job char(10),

sal number(10,2), Dept_No number(5) constraint Emp_Dept_No_fk references
Dept(Dept_No) );
 3. Referential Integrity constraint
Consider following schemas.
i) Course details (coursecode, coursename, fees)
ii) Student details :- (Student-id, name, marks, subjects, course code, dept.)
Identify :- l) Primary key 2) Super key 3) Foreign key
With justification, draw and explain parent child relationship for above schemas.
Primary key:
1) Coursecode attribute is a primary key of Course details relation
2) Student-id attribute is a primary key of Student details relation
Super key:
1. Course details (coursecode, coursename)
2. Student details (Student-id, Student-id +name)
3. Referential Integrity constraint
 3. Referential Integrity constraint
Foreign key: coursecode is a foreign key of student details relation.
- Since there exist a common attribute coursecode in both tables Course details
and Student details.
- coursecode attribute uniquely identifies course, is a primary key of Course
details.
- A student can have a course that exist in Course details table and hence we need
to reference coursecode in Student details table from coursecode in Course details
table.
- To ensure this referential integrity, coursecode in Student details table becomes
the foreign key referenced to coursecode primary key from Course details table.
 E-R Model
- E-R stands for Entity Relationship.

- E-R Diagram is a visual representation of data that describes how data is related
to each other.

- In other words, it is graphical technique for understanding and organizing the

data independent of the actual database implementation.

- defines the conceptual view of a database.

- works around real-world entities and the associations among them.

 E-R Model
Entity :-
- It is a thing or an object in a real world that can be distinguished from all other objects.
- An Entity may be an object with a physical existence i.e. a particular person, car, house, or
employee or it may be an object with a conceptual existence i.e. a company, a job, or a
university course.
- An Entity represented using rectangles.
Syntax Example

Entity Student
 E-R Model
Relationship :-
- A relationship represents the association between entity types.
- For example. ‘Enrolled in’ is a relationship that exists between entity Student and
Course.
- In ER diagram, relationship is represented by a diamond and connecting the entities
with lines.
Example
 E-R Model
Degree of a Relationship :-
- It refers to number of entities participated in the relation.
A) Unary Relationship
B) Binary Relationship
C) Ternary Relationship
D) Quaternary Relationship
 ER Model - Degree of a Relationship

a) Unary Relationship:
- When there is only ONE entity set participating in a relation, the relationship is called as
unary relationship.
- For example, one person is married to only one person.
 ER Model - Degree of a Relationship

b) Binary Relationship –
- When there are TWO entities set participating in a relation, the relationship is
called as binary relationship.
- For example, Student is enrolled in Course.
 ER Model - Degree of a Relationship

c) Ternary Relationship –
- When there are THREE entities set participating in a relation, the relationship is
called as Ternary relationship.
- For example, Teacher teahces the subject to the student.
 ER Model - Degree of a Relationship
d) Quaternary Relationship –
- When four entities get associated to form a relationship is called quaternary
relationship.
- For example studies is a relationship where four entities are involved-
STUDENT, TEACHER, COURSE_MATERIAL and SUBJECT. A Student is studying a
subject by a teacher with the help of the course material.
 E-R Model
Attributes :-
- An Attribute describes a property or characteristic of an entity.
- For example, Name, Age, Address can be attributes of a Student.

- An attribute is represented using ellipse.

Attribute

- For example:
Name Age Address
 E-R Model
Types of Attributes :-
a) Simple attribute−
PHONE
- these are atomic values, which cannot be divided further. NO
- For example, a student's phone number is an atomic value of 10 digits.

b) Single-valued attribute-
- If an attribute can take only a single value for each entity instance,
it is a single valued attribute.
- For example age of a student can be single valued attribute.
25
- It can take only one value for a particular student.
 E-R Model
c) Composite attribute-

- Composite attributes can be divided into parts.

- These are made of more than one simple attribute.
- For example, a student's complete name may have first_name and last_name.
 E-R Model
d) Multi-valued attribute
- If an attribute can take more than one value for each entity, it is a multi-valued
attribute.
- For example telephone number of an employee, a particular employee may
have multiple telephone numbers.
- In ER modeling, notation for multi-valued attribute is (double ellipse) as
follows: Example
 E-R Model
e) Derived attribute
- an attribute which can be calculated or derived based on other attributes is a
derived attribute.
- For example age of an employee can be calculated from date of birth and
current date.
- In ER modeling, notation for derived attribute is
(Dashed Ellipse) given below:
Example
 E-R Model
f) Key Attribute
- The attribute which uniquely identifies each entity in the entity set is called
the key attribute.
- The key attribute is represented by an ellipse with the text underlined.
- It is used to represent Primary key.
- For example, Roll_No will be unique for each student.
Example

Key
Attribute
 E-R Model
Entity Set
- collection of similar types of entities.
- set of entities of the same type that share the same properties or attributes.
- For e.g. the set of all students is defined as entity set.
- There are two types of entity set:
a) Strong Entity Set
b) Weak Entity Set
 E-R Model
a) Strong Entity Set:
- The entity set that have sufficient attributes to form a primary key is called as
Strong entity set.
- represented by a rectangle.
- also called as owner entity set.
- relationship between two strong entity set is represented by a diamond symbol.

Strong Entity
 E-R Model
b) Weak Entity Set:
- The entity set which does not have sufficient attributes to form a primary key is
called as Weak entity set.
- Weak entity depends on the strong entity for its existence.
- Weak entity is represented by double rectangle.
- The relationship between one strong entity set and one weak entity set is
represented by a double diamond sign.
 E-R Model
Entity Set -example
 E-R Model
Difference between Strong and Weak Entity Set

Strong Entity Set Weak Entity Set

It has sufficient attributes to form a It does not have sufficient attributes to
primary key form a primary key.
It is represented by a rectangle. It is represented by double rectangle.
Strong entity set is the owner entity set, Weak Entity set depends on the strong
it does not depend on other. entity for its existence.
The relationship between two strong The relationship between one strong
entity set is represented by a diamond entity set and one weak entity set is
symbol. represented by a double diamond sign.
The line connecting strong entity set with The line connecting weak entity set with
relationship is single. identifying relationship is double.
 E-R Model
Symbols used in E-R Diagram
 E-R Diagram
Customer- Branch- Account Relationship
 E-R Diagram
Library Management System maintaining data about book and book Borrower
 E-R Diagram
Car Insurance Company whose customer owns one or more cars.
Assume suitable attributes
 E-R Diagram
Library Management System maintaining data about book and book Borrower
 E-R Diagram
Library Management System, data about books, borrowers, issue and return
details, Fine collection, Supplies of Books
 Normalization
- Normalization is a database design technique which organizes tables in a
manner that reduces redundancy and dependency of data.
- It divides larger tables to smaller tables and links them using
relationships.
- It is a multi-step process that puts data into tabular form, removes
duplicated data from the related tables.
- Purpose/Need of normalization:
1. Eliminating redundant data.
2. Ensuring data dependencies or Consistency
 Normalization
Problems without Normalization :-
- If a table is not properly normalized and have data redundancy then it will not only take
extra memory space but also it is difficult to handle and update the database.
- If database is not normalized, Insertion, Updation and Deletion Anomalies(error prone
situation) are there .
- To understand, anomalies let us take an example of a Student table.

- In the above table, we have data of 4 students.

- As we can see, data for the fields branch, hod(Head of Department) and Telno is repeated
for the students who are in the same branch in the college, this is Data Redundancy.
 Normalization
i) Insertion Anomaly:
- Suppose for a new admission, until and unless a student opts for a branch, data
of the student cannot be inserted, or else we will have to set the branch
information as NULL.
- Also, if we have to insert data of 100 students of same branch, then the branch
information will be repeated for all those 100 students.
- These scenarios are nothing but Insertion anomalies.
ii) Updation Anomaly:
- If XYZ leaves the college or he/she is no longer the HOD of IF department, then in
that case all the student records will have to be updated, and if by mistake we
miss any record, it will lead to data inconsistency. This is Updation anomaly.
 Normalization
iii) Deletion Anomaly:
- In our Student table, two different information are kept together, Student
information and Branch information. Hence, at the end of the academic year,
if student records are deleted, we will also lose the branch information.
- This is called as Deletion anomaly.
 Normalization
Advantages of Normalization

- More efficient data structure.

- Avoid redundant fields or columns.
- More flexible data structure i.e. we should be able to add new rows and data
values easily.
- Better understanding of data.
- Ensures that distinct tables exist when necessary.
- Easier to maintain data structure i.e. it is easy to perform.
- Minimizes data duplication.
 Normalization - Functional Dependency
- 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.
- It is denoted as X → Y .
- The left side of Functional Dependency is known as a determinant, and the right
side is known as a dependent. Here, Y is dependent on X.
- For example: Assume we have an employee table with attributes:
- Emp_id, Emp_Name, Emp_Address.
- Here Emp_id can uniquely identify the Emp_Name of employee table because if
we know the Emp_id, we can tell the employee name associated with it.
- Functional dependency can be written as: Emp_id → Emp_Name
- We can say that Emp_Name is functionally dependent on Emp_id.
 Normalization - Functional Dependency

Types of Functional Dependency

i) Trivial functional dependency

ii) Non-trivial functional dependency

iii) Multivalued dependency

iv) Transitive dependency

 Normalization - Functional Dependency
i. Trivial functional dependency

- The dependency of an attribute on a set of attributes is known as trivial

functional dependency if the set of attributes includes that attribute.
- Symbolically: A ->B is trivial functional dependency if B is a subset of A.
- The following dependencies are also trivial: A->A & B->B
- For example: Consider a table with two columns Student_id and Student_Name.
- {Student_Id, Student_Name} -> Student_Id is a trivial functional dependency as
Student_Id is a subset of {Student_Id, Student_Name}.
 Normalization - Functional Dependency
ii. Non -Trivial functional dependency
- If a functional dependency X->Y holds true where Y is not a subset of X then this
dependency is called non trivial Functional dependency.
- For example: An employee table with three attributes:
- emp_id, emp_name, emp_address.
- The following functional dependencies are non-trivial:
emp_id -> emp_name (emp_name is not a subset of emp_id)
emp_id -> emp_address (emp_address is not a subset of emp_id)
- On the other hand, the following dependencies are trivial:
{emp_id, emp_name} -> emp_name
as [ emp_name is a subset of {emp_id, emp_name}]
 Normalization - Functional Dependency
iii. Multivalued dependency

- Multivalued dependency is one where more than one attributes are dependent on
single attribute.

- Multivalued dependency occurs when two attributes in a table are independent to

each other but both depend on a third attribute.

- 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.
 Normalization - Functional Dependency
- For example: Suppose there is a bike manufacturer company which produces two
colors(white and black) of each model every year.

- Here COLOR and MANU_YEAR are dependent on BIKE_MODEL and independent of each other.
- Here, two columns can be called as multivalued dependent on BIKE_MODEL.
- They are represented like:
BIKE_MODEL →→ MANU_YEAR
BIKE_MODEL →→ COLOR
- Here, "BIKE_MODEL multidetermines MANU_YEAR" and "BIKE_MODEL multidetermines COLOR".
 Normalization - Functional Dependency
iv. Transitive dependency
- A functional dependency is said to be transitive if it is indirectly formed by two functional
dependencies. A transitive dependency can occur in a relation of three or more attributes.
- e.g. X -> Z is a transitive dependency if the following three functional dependencies hold true
X->Y
Y does not ->X
Y->Z

- {Book} ->{Author} (if we know the book, we knows the author name)
{Author} -> {Author_age}
- Therefore as per the rule of transitive dependency: {Book} -> {Author_age} should be there
because if we know the book name we can know the author’s age.
 Normal Forms
First Normal Form (1NF)
- 1NF is a property of a relation in a relational database.
- A database is in first normal form if it satisfies the following conditions:
i) Contains only atomic values
ii) There are no repeating group.
- An atomic value is a value that cannot be divided, means it should have single
valued attributes.
- There are no repeating groups of data. This means a table should not contain
repeating columns.
 Normal Forms
First Normal Form- Example
- This table is not in first normal form
because the [Color] column can
contain multiple values.
- As the first row includes values "red"
and "green" values for [Color]
column.
- To bring this table to first normal
form, we split the table into two
tables.
 Normal Forms
First Normal Form- Example

- We have these 2 resulting tables:

TABLE_PRODUCT_PRICE and TABLE_PRODUCT_COLOR
- Now first normal form is satisfied, as the columns in each table holds
single value.
 Normal Forms
Second Normal Form (2NF)
- Second Normal Form applies to relations with composite keys, that is, relations with a
primary key composed of two or more attributes.
- A relation with a single-attribute primary key is automatically in at least 2NF.
- A database is in second normal form if it satisfies the following conditions:
i) It is in first normal form
ii) A relation must not contain any partial dependency.
- A partial dependency means if the non-key attributes depend on the part of candidate key
then it is said to be partial dependency.
- The normalization of 1NF relations to 2NF involves the removal of partial dependencies. If a
partial dependency exists, we remove the partially dependent attribute(s) from the
relation by placing them in a new relation.
 Normal Forms
Second Normal Form- Example

- Course_Fee can’t alone decide the value of Course_No or Stud_No;

- Course_Fee together with Stud_No can’t decide the value of Course_No;
- Course_Fee together with Course_No can’t decide the value of Stud_No;
- Hence, Course_Fee would be a non-prime attribute, as it does not belong to the one only
candidate key {Stud_No, Course_No} ;
- But, Course_No -> Course_Fee, i.e., Course_Fee is dependent on Course_No , which is a proper
subset of the candidate key.
- Non-prime attribute Course_Fee is dependent on a proper subset of the candidate key, which is a
partial dependency and so this relation is not in 2NF.
 Normal Forms
Second Normal Form- Example
- To convert the above relation to 2NF, we need to split the table into two tables such as :
Table 1: Stud_No, Course_No
Table 2: Course_No, Course_Fee
 Normal Forms
Second Normal Form- Example
- Consider a single table consisting following columns. Convert it into 2NF :
- (supplier_no, supplier_name, supplier_city, order_no, order_quantity, order_amount,
product_code, product_name)
- To convert it into 2NF, We have to decompose the given table into two tables with fully
functional dependencies and establishing a referential integrity constraint relationship
among the two tables.
- ANS :- Given Table Schema : (supplier_no, supplier_name, supplier_city, order_no,
order_quantity, order_amount, product_code, product_name)
- Table 1- Supplier Details (supplier_no, supplier_name, supplier_city, order_no)
- Table 2 - Order Details (order_no, order_ quantity, order_amount, product_code,
product_name)
- Now the above two tables are in 2NF.
 Normal Forms

Third Normal Form

- 3rd Normal Form Definition:
- A database is in third normal form if it satisfies the following conditions:
i) It is in second normal form
ii) There is no transitive functional dependency
- Transitive functional dependency means if A is functionally dependent on B, and B is
functionally dependent on C. Then, A is transitively dependent on C via B.
 Normal Forms
Third Normal Form- Example

- In the table, [Book ID] determines [Genre ID], and [Genre ID] determines [Genre Type].
- Therefore, [Book ID] determines [Genre Type] via [Genre ID] here, we have transitive
functional dependency so this structure does not satisfy third normal form.
- To bring this table to third normal form, we split the table into two as follows:
 Normal Forms
Third Normal Form- Example

- Now all non-key attributes are fully functional dependent only on the primary key.
- In [TABLE_BOOK], both [Genre ID] and [Price] are only dependent on [Book ID].
- In [TABLE_GENRE], [Genre Type] is only dependent on [Genre ID].
 Normal Forms
Third Normal Form- Example
- Consider a single table consisting following columns. Convert it into 3NF :
(supplier_no, supplier_name, supplier_city, order_no, order_quantity, order_amount,
product_code, product_name)
- To convert the above tables in 3NF ,We have to decompose them in three tables satisfying
the transitive dependencies property.
ANS : Given Table Schema - (supplier_no, supplier_name, supplier_city, order_no,
order_quantity, order_amount, product_code, product_name)
- Table 1- Supplier Details (supplier_no , supplier_name, supplier_city)
- Table 2- Product Details (product_code, product_name)
- Table 3- Order Details (order_no, product_code, supplier_no, order_ quantity,
order_amount)
- Hence the above three tables are satisfying Transitive dependencies. Thus they are in 3NF.
 Normal Forms
Boyce Codd Normal Form
- BCNF is the advance version of 3NF.
- For BCNF, the table should be in 3NF and for every Functional Dependency, Left Hand Side
is a super key.
- Example: Let's assume there is a company where employees work in more than one
department. They store the data like this:

- Functional dependencies in the table above:

emp_id -> emp_nationality and emp_dept -> {dept_type, dept_no}
- Candidate key: {emp_id, emp_dept}
- The table is not in BCNF as neither emp_id nor emp_dept alone are keys.
- To make the table comply with BCNF we can break the table in three tables like this:
 Normal Forms
Boyce Codd Normal Form- Example

emp_dept_mapping table

- Functional dependencies:
emp_id -> emp_nationality
emp_dept -> {dept_type, dept_no}
- Candidate keys:
For first table: emp_id
For second table: emp_dept
For third table: {emp_id, emp_dept}
- This is now in BCNF as in both the functional dependencies left side part is a key
 Normal Forms
Difference between 3NF and BCNF

3NF BCNF
There should be no transitive functional For any trivial dependency in a relation R
dependency. say X->Y,
Where X should be a super key of relation R.
3NF can be obtained without sacrificing all Dependencies may not be preserved in BCNF.
dependencies.
Lossless decomposition can be achieved in Lossless decomposition is hard to achieve in
3NF. BCNF.
More redundancy. Less redundancy.
3NF can't capture all the anomalies. BCNF can capture all the anomalies.