What is database Management System?

A Database Management System (DBMS) is a software system that is designed to manage and
organize data in a structured manner. It allows users to create, modify, and query a database, as well
as manage the security and access controls for that database.

Advantages of Database Management System:

The advantages of database management systems are:

1. Data Security: The more accessible and usable the database, the more it is prone to security
issues. As the number of users increases, the data transferring or data sharing rate also increases
thus increasing the risk of data security. It is widely used in the corporate world where
companies invest large amounts of money, time, and effort to ensure data is secure and used
properly. A Database Management System (DBMS) provides a better platform for data privacy
and security policies thus, helping companies to improve Data Security.

2. Data integration: Due to the Database Management System we have access to well-managed
and synchronized forms of data thus it makes data handling very easy and gives an integrated
view of how a particular organization is working and also helps to keep track of how one
segment of the company affects another segment.

3. Data abstraction: The major purpose of a database system is to provide users with an abstract
view of the data. Since many complex algorithms are used by the developers to increase the
efficiency of databases that are being hidden by the users through various data abstraction
levels to allow users to easily interact with the system.

4. Reduction in data Redundancy: When working with a structured database, DBMS provides
the feature to prevent the input of duplicate items in the database. for e.g. – If there are two
same students in different rows, then one of the duplicate data will be deleted.

5. Data sharing: A DBMS provides a platform for sharing data across multiple applications and
users, which can increase productivity and collaboration.

6. Data consistency and accuracy: DBMS ensures that data is consistent and accurate by
enforcing data integrity constraints and preventing data duplication. This helps to eliminate data
discrepancies and errors that can occur when data is stored and managed manually.

7. Data organization: A DBMS provides a systematic approach to organizing data in a structured

way, which makes it easier to retrieve and manage data efficiently.

8. Efficient data access and retrieval: DBMS allows for efficient data access and retrieval by
providing indexing and query optimization techniques that speed up data retrieval. This reduces
the time required to process large volumes of data and increases the overall performance of the
system.

Application of DBMS:
There are different fields where a database management system is utilized. Following are a few
applications that utilize the information base administration framework.
 1. Railway Reservation System:
In the rail route reservation framework, the information base is needed to store the record or
information of ticket appointments, status of train’s appearance, and flight. Additionally, if trains get
late, individuals become acquainted with it through the information base update.

2. Library Management System

There are many books in the library so; it is difficult to store the record of the relative multitude of
books in a register or duplicate. Along these lines, the data set administration framework (DBMS) is
utilized to keep up all the data identified with the name of the book, issue date, accessibility of the
book, and its writer.

3. Banking
Database the executive’s framework is utilized to store the exchange data of the client in the
information base.

4. Education Sector
Presently, assessments are led online by numerous schools and colleges. They deal with all
assessment information through the data set administration framework (DBMS). In spite of that
understudy’s enlistments subtleties, grades, courses, expense, participation, results, and so forth all
the data is put away in the information base.

5. Credit card exchanges

The database Management framework is utilized for buying on charge cards and age of month to
month proclamations.

6. Social Media Sites

We all utilization of online media sites to associate with companions and to impart our perspectives
to the world. Every day, many people group pursue these online media accounts like Pinterest,
Facebook, Twitter, and Google in addition to. By the utilization of the data set administration
framework, all the data of clients are put away in the information base and, we become ready to
interface with others.
7. Broadcast communications
Without DBMS any media transmission organization can’t think. The Database the executive’s
framework is fundamental for these organizations to store the call subtleties and month to month
postpaid bills in the information base.

8. Accounting and Finance

The information base administration framework is utilized for putting away data about deals, holding
and acquisition of monetary instruments, for example, stocks and bonds in a data set.

Physical and Logical Data Independence:

1. Logical Data Independence:

o Logical data independence refers characteristic of being able to change the conceptual schema
without having to change the external schema.
o Logical data independence is used to separate the external level from the conceptual view.
o If we do any changes in the conceptual view of the data, then the user view of the data would
not be affected.
o Logical data independence occurs at the user interface level.

2. Physical Data Independence

o Physical data independence can be defined as the capacity to change the internal schema
without having to change the conceptual schema.
o If we do any changes in the storage size of the database system server, then the Conceptual
structure of the database will not be affected.
o Physical data independence is used to separate conceptual levels from the internal levels.
o Physical data independence occurs at the logical interface level.

Difference between Schema and Instance in DBMS:

“Schema” and “Instance” are key ideas in a database management system (DBMS) that help
organize and manage data. Let’s begin by examining their distinctions from one another.
Instances:

An Instance is the state of an operational database with data at any given time. It contains a
snapshot of the database. The instances can be changed by certain CRUD operations, such as like
addition, and deletion of data. It may be noted that any search query will not make any kind of
changes in the instances.
Example:

Let’s say a table teacher in our database whose name is School, suppose the table has 50 records so
the instance of the database has 50 records for now and tomorrow we are going to add another fifty
records so tomorrow the instance has a total of 100 records. This is called an instance.

Schema:
Schema is the overall description of the database. The basic structure of how the data will be stored
in the database is called schema.
Schema is of three types: Logical Schema, Physical Schema and view Schema.
 Logical Schema – It describes the database designed at a logical level.
 Physical Schema – It describes the database designed at the physical level.
 View Schema – It defines the design of the database at the view level.

Schema

Difference Between Schema and Instance:

Schema Instance

It is the collection of information stored in

It is the overall description of the database.
a database at a particular moment.
 Schema Instance

Data in instances can be changed using

The schema is same for the whole database.
addition, deletion, and updation.

Does not change Frequently. Changes Frequently.

Defines the basic structure of the database i.e. It is the set of Information stored at a
how the data will be stored in the database. particular time.

Data Dictionary:
A Data Dictionary can be defined as a collection of information on all data elements or contents of
databases such as data types, and text descriptions of the system.
Types of Data Dictionary
Data Dictionary is basically of two types. We will discuss each of them.
 Integrated Data Dictionary
 Stand Alone Data Dictionary

The Three Levels of DBMS Architecture:

The 3-Tier Schema consists of three distinct levels, each with its own purpose and function:

1. Internal Level: The internal level, or physical schema, describes the physical storage structure of
the database. It details how data is stored in blocks, the storage space allocations, access paths, and
the optimization of internal structures. This level is concerned with the technical aspects of data
storage, such as data compression, encryption, and the use of data structures like B-Trees and
hashing1.
2. Conceptual Level: Also known as the logical level, the conceptual schema provides a blueprint of
the entire database structure. It outlines what data is stored and the relationships among those data.
This level abstracts the internal details of data storage, focusing instead on the overall design of
the database. Database administrators and developers typically interact with the DBMS at this
level1.
3. External Level: The external level comprises multiple schemas or views, each tailored to different
user groups. These views, also referred to as subschemas, present a portion of the database that is
relevant to a particular group, hiding the rest. For example, a faculty member may have a view that
includes course details of students, while students may have a view that encompasses academic,
account, and hostel information

Data Models
Data Model is the modeling of the data description, data semantics, and consistency constraints of the
data.
There are 4 types of data models:

1) Relational Data Model

2) Entity-Relationship Data Model
3) Object-based Data Model
4) Semistructured Data Model

Object-based Data Model:

An extension of the ER model with notions of functions, encapsulation, and object identity, as well.
This model supports a rich type system that includes structured and collection types. Thus, in 1980s,
various database systems following the object-oriented approach were developed. Here, the objects
are nothing but the data carrying its properties.

Entity-Relationship Model( ER Model):

It is a high-level data model which is used to define the data and the relationships between them. It
is basically a conceptual design of any database which is easy to design the view of data.
Components of ER Model:
1. Entity: An entity is referred to as a real-world object. It can be a name, place, object, class, etc.
These are represented by a rectangle in an ER Diagram.
2. Attributes: An attribute can be defined as the description of the entity. These are represented
by Ellipse in an ER Diagram. It can be Age, Roll Number, or Marks for a Student.
3. Relationship: Relationships are used to define relations among different entities. Diamonds
and Rhombus are used to show Relationships.
Entity Relationship Diagram – ER
Diagram in DBMS
An Entity–relationship model (ER model) describes the structure of a
database with the help of a diagram, which is known as Entity Relationship
Diagram (ER Diagram). An ER model is a design or blueprint of a database
that can later be implemented as a database. The main components of E-R
model are: entity set and relationship set.

What is an Entity Relationship Diagram (ER

Diagram)?
An ER diagram shows the relationship among entity sets. An entity set is a
group of similar entities and these entities can have attributes. In terms of
DBMS, an entity is a table or attribute of a table in database, so by showing
relationship among tables and their attributes, ER diagram shows the
complete logical structure of a database. Lets have a look at a simple ER
diagram to understand this concept.

A simple ER Diagram:

In the following diagram we have two entities Student and College and their
relationship. The relationship between Student and College is many to one as
a college can have many students however a student cannot study in multiple
colleges at the same time. Student entity has attributes such as Stu_Id,
Stu_Name & Stu_Addr and College entity has attributes such as Col_ID &
Col_Name.
Here are the geometric shapes and their meaning in an E-R Diagram. We will
discuss these terms in detail in the next section(Components of a ER
Diagram) of this guide so don’t worry too much about these terms now, just go
through them once.

Rectangle: Represents Entity sets.

Ellipses: Attributes
Diamonds: Relationship Set
Lines: They link attributes to Entity Sets and Entity sets to Relationship Set
Double Ellipses: Multivalued Attributes
Dashed Ellipses: Derived Attributes
Double Rectangles: Weak Entity Sets
Double Lines: Total participation of an entity in a relationship set

Components of a ER Diagram

As shown in the above diagram, an ER diagram has three main components:

1. Entity
2. Attribute
3. Relationship

1. Entity
An entity is an object or component of data. An entity is represented as
rectangle in an ER diagram.
For example: In the following ER diagram we have two entities Student and
College and these two entities have many to one relationship as many
students study in a single college. We will read more about relationships later,
for now focus on entities.
Weak Entity:
An entity that cannot be uniquely identified by its own attributes and relies on
the relationship with other entity is called weak entity. The weak entity is
represented by a double rectangle. For example – a bank account cannot be
uniquely identified without knowing the bank to which the account belongs, so
bank account is a weak entity.

2. Attribute
An attribute describes the property of an entity. An attribute is represented as
Oval in an ER diagram. There are four types of attributes:

1. Key attribute
2. Composite attribute
3. Multivalued attribute
4. Derived attribute

1. Key attribute:
A key attribute can uniquely identify an entity from an entity set. For example,
student roll number can uniquely identify a student from a set of students. Key
attribute is represented by oval same as other attributes however the text of
key attribute is underlined.

2. Composite attribute:

An attribute that is a combination of other attributes is known as composite

attribute. For example, In student entity, the student address is a composite
attribute as an address is composed of other attributes such as pin code,
state, country.

3. Multivalued attribute:
An attribute that can hold multiple values is known as multivalued attribute. It
is represented with double ovals in an ER Diagram. For example – A person
can have more than one phone numbers so the phone number attribute is
multivalued.

4. Derived attribute:
A derived attribute is one whose value is dynamic and derived from another
attribute. It is represented by dashed oval in an ER Diagram. For example –
Person age is a derived attribute as it changes over time and can be derived
from another attribute (Date of birth).
E-R diagram with multivalued and derived attributes:

3. Relationship
A relationship is represented by diamond shape in ER diagram, it shows the
relationship among entities. There are four types of relationships:
1. One to One
2. One to Many
3. Many to One
4. Many to Many

1. One to One Relationship

When a single instance of an entity is associated with a single instance of

another entity then it is called one to one relationship. For example, a person
has only one passport and a passport is given to one person.

2. One to Many Relationship

When a single instance of an entity is associated with more than one

instances of another entity then it is called one to many relationship. For
example – a customer can place many orders but a order cannot be placed by
many customers.
3. Many to One Relationship

When more than one instances of an entity is associated with a single

instance of another entity then it is called many to one relationship. For
example – many students can study in a single college but a student cannot
study in many colleges at the same time.

4. Many to Many Relationship

When more than one instances of an entity is associated with more than one
instances of another entity then it is called many to many relationship. For
example, a can be assigned to many projects and a project can be assigned
to many students.

Total Participation of an Entity set

Total participation of an entity set represents that each entity in entity set must
have at least one relationship in a relationship set. It is also called mandatory
participation. For example: In the following diagram each college must have
at-least one associated Student. Total participation is represented using
a double line between the entity set and relationship set.
Partial participation of an Entity Set
Partial participation of an entity set represents that each entity in the entity set
may or may not participate in the relationship instance in that relationship set.
It is also called as optional participation

Partial participation is represented using a single line between the entity set
and relationship set.

Example: Consider an example of an IT company. There are many

employees working for the company. Let’s take the example of relationship
between employee and role software engineer. Every software engineer is
an employee but not every employee is software engineer as there are
employees for other roles as well, such as housekeeping, managers, CEO
etc. so we can say that participation of employee entity set to the software
engineer relationship is partial.
Explanation of Keys in DBMS
In a DBMS, KEYS are attributes or sets of attributes that enable the identification of
a row or tuple within a relation or table. They establish connections between different
tables and assist in uniquely identifying a row by utilizing one or more columns in the
table.

Types of Keys in DBMS

Now we have understood what is a key in DBMS, let’s look at the major types of
keys in DBMS in detail.

1. Primary Key

This type of keys in DBMS refers to a column that uniquely identifies all the records
within that table. A table has one primary key only, and this key must not contain
repeated or duplicated values across its rows. Each value within the primary
key must be unique, with no repetitions allowed.

Applying the PK (PRIMARY KEY) constraint to a column or set of columns ensures

that they cannot have null values or duplicates. Furthermore, any foreign key that
references the primary key is unable to modify the values present in the primary key.

Properties of a Primary Key

 The Primary Key field shouldn’t be left NULL; the Primary Key column must
contain a value.
 In that column, no two rows in the table may contain identical values.
 If a foreign key in a DBMS refers to the primary Key, no value may be altered
or modified in this primary key column.


Examples of Primary Keys

In this example, the student ID is the primary key.
 StudID Roll No First Name Last Name Email

1 11 Tom Prince abc@gmail.com

2 12 Nick Wright xyz@gmail.com

3 13 Dana Natan mno@gmail.com

Guidelines for Choosing a Primary Key

1. Uniqueness is the most crucial element while selecting this key in DBMS. It
means that this column’s value does not occur in any other table row.
2. The definition and values shouldn’t be altered. While altering a PK column
value would need updating all referenced rows in the child (related) table,
altering a PK’s columns would necessitate redefining all pertinent foreign
keys.
3. If a composite primary key is used, no single column or smaller group of
columns should be able to identify each individual uniquely.
4. Use as few columns as you can, and if you can, pick columns whose values
are simple to read and recall.

2. Candidate Key

Candidate keys play a vital role in upholding the integrity and consistency of a
database. The purpose of this key in DBMS is to guarantee each row’s uniqueness
and independent identification within a table. Additionally, candidate keys enforce
relationships between tables, ensuring data integrity and maintaining overall
database consistency.

Properties of a candidate key

 It must have distinct values.

 Create a unique identifier for each table record.

Examples of candidate keys

 StudID Roll No First Name Last Name Email

1 11 Tom Prince abc@gmail.com

2 12 Nick Wright xyz@gmail.com

3 13 Dana Natan mno@gmail.com

The candidate keys Roll No., Stud ID, and Email in the table enable us to identify
each student record uniquely.

Differences Between Primary and Candidate keys

Primary Key Candidate Key

A primary key is a column that allows each A column that can uniquely identify
entry in a database to be identified only once. each record in a database is sometimes
It is selected as the primary key for the table referred to as a candidate key. It might
from the list of potential keys. be used as the primary key.

A candidate key is also a unique

A primary key is a unique identifier for a
identifier for a record in a database
record in a database table.
table.

There can be multiple candidate keys

There can be only one primary key in a table.
in a table.

The primary key enforces entity integrity, Candidate keys are potential candidates

The primary key is chosen by the database A candidate key can be chosen from
designer or administrator. the set of candidate keys for a table.

3. Super Key

The collection of all keys enabling us to recognize every row in the table is a super
key. This type of key in DBMS specifies that all the table columns that may identify
the columns uniquely function as the super keys.

Properties of a super key

  A super key must ensure that each record in a table is unique.
 Nevertheless, the minimal collection of characteristics that can guarantee
uniqueness should be a super key.
 Multiple subsets that are likewise regarded as super keys can exist for a
super key.

4. Foreign Key: To create connections between two accessible tables, we

employ a foreign key. Every value in a column or collection must match the primary
key in the referential table for the foreign key to function. We can preserve referential
integrity and data integrity with the aid of a foreign key.

Properties of a foreign key

 It is a key that serves as both a secondary key and a primary key in two
different tables.
 At any given time, it combines two or more relations.
 They serve as cross-references for the tables.

Examples of foreign keys

Dept code Dept name

121 Science

213 English

513 Computer

Teacher ID Fname Lname

B002 David Warner

B017 Sara Joseph

 B009 Mike Brunton

In this Key in DBMS example, we have two tables: instructor and department at a
school. However, it is hard to distinguish which instructor is assigned to which
division.

We can link the two tables in this table by adding the Foreign Key in Deptcode to the
Teacher name.

Importance of foreign keys in DBMS

Data in one table is connected to another through foreign keys. To develop a manner
of cross-referencing two columns, a foreign key column in one table links to the
column in another table with unique values.

5. Alternate Key

A key in DBMS might be selected as the main Key in a table in multiple ways. Any
key that has the potential to replace the primary key but is not yet the primary key is
considered an alternate key. It’s a prospective main key that hasn’t been selected
yet.

Properties of an alternate key

 Alternate keys refer to all keys that are not main keys.
 It’s a backup key.
 It has two or more fields that allow it to recognize two or more records.
 These criteria are reiterated.

Examples of alternate keys

StudID Roll No First Name Last Name Email

1 11 Tom Prince abc@gmail.com

 2 12 Nick Wright xyz@gmail.com

3 13 Dana Natan mno@gmail.com

StudID, Roll No., and Email serves as the main keys. However, because StudID is
the main key, Roll No. and Email is now the secondary key.

6. Compound Key
This key in DBMS contains two or more characteristics that recognise a specific
record exclusively. It’s conceivable that none of the columns in the database are
unique on their own. However, when paired with the additional column or columns,
the composite key combination becomes unique. Each record in the table is to be
uniquely identified using the database’s compound key.

Properties of a compound key

 Each record in a table must be guaranteed unique by a compound key.

 The bare minimal collection of characteristics necessary to assure uniqueness
should be a compound key.
 A compound key attribute order is essential.

Examples of compound keys

Order No Product ID Productname Quantity

B005 JAP1024 Mouse 5

B005 JHD1345 USB 10

B005 KDL0973 LCD Monitor 20

B002 FRG1204 USB 6

B004 JUW1287 Laser printer 2

Below is the example of this key in DBMS:

OrderNo and ProductID cannot be the main key since they do not uniquely identify a
record. A compound key combining the Order ID and Product ID might be utilized to
identify each record uniquely.

Importance of compound keys in DBMS

Compound keys are always constructed from two or more other tables’ primary keys.
Both keys uniquely identify data in their respective tables, but both are required to do
so in the table utilizing the compound key.

Comparison of 6 Types of keys in DBMS

Here’s a comparison between different types of keys in a relational database
management system (DBMS) presented in a table format:

Null
Key Definitio Unique Alterati
Valu Purpose Index Usage
Type n ness on
es

Uniquely Data Create May be

identifies Not integrity, s Within complex
Primar Require
each Allo record Uniqu same , impact
y Key d
record in wed identific e table other
a table. ation. Index tables.

Data
Establish
consisten More
es a
Not cy, May Betwee flexible
Foreig relations Allo
Require relations create n for
n Key hip wed
d hip Index tables mainten
between
maintena ance.
tables.
nce.

Alternati
Backup May
Candid ve Not May Within
Require primary become
ate unique Allo create same
d key primary
Key keys that wed Index table
options. key.
could be
 Null
Key Definitio Unique Alterati
Valu Purpose Index Usage
Type n ness on
es

primary
keys.

Combina
tion of
Concept May Concep
Super attributes Require Allo
ual, not create tual N/A
Key that d wed
enforced. Index use
uniquely
identify.

Combine
Specializ Create May be
d
Comp Not ed s Within complex
attributes Require
osite Allo unique Comp same , impact
used as a d
Key wed identific osite table perform
single
ation. Index ance.
key.

Ensures Enforce Create

May be
column(s uniquene s Within
Uniqu Require Allo used as
) have ss, no Uniqu same
e Key d wed primary
unique primary e table
key.
values. key. Index

Artificial
Enhance
keys Create Generall
d data
Surrog assigned Not s Within y static,
Require privacy,
ate for Allo Uniqu same non-
d data
Key record wed e table changin
warehou
identific Index g.
sing.
ation.
Cardinality in DBMS (Mapping Constraints)

Cardinality means how the entities are arranged to each other or what is the relationship
structure between entities in a relationship set. In a Database Management System,
Cardinality represents a number that denotes how many times an entity is participating
with another entity in a relationship set. The Cardinality of DBMS is a very important
attribute in representing the structure of a Database. In a table, the number of rows or
tuples represents the Cardinality.

There are four types of Cardinality Mapping in Database Management Systems:

1. One to one
2. Many to one
3. One to many
4. Many to many

One to one cardinality is represented by a 1:1 symbol. In this, there is at most one
relationship from one entity to another entity. There are a lot of examples of one-to-one
cardinality in real life databases.

For example, one student can have only one student id, and one student id can belong
to only one student. So, the relationship mapping between student and student id will be
one to one cardinality mapping.

Another example is the relationship between the director of the school and the school
because one school can have a maximum of one director, and one director can belong to
only one school.
Many to One Cardinality:
In many to one cardinality mapping, from set 1, there can be multiple sets that can make
relationships with a single entity of set 2. Or we can also describe it as from set 2, and one
entity can make a relationship with more than one entity of set 1.

One to one Cardinality is the subset of Many to one Cardinality. It can be represented
by M:1.

For example, there are multiple patients in a hospital who are served by a single doctor,
so the relationship between patients and doctors can be represented by Many to one
Cardinality.

One to Many Cardinalities:

In One-to-many cardinality mapping, from set 1, there can be a maximum single set that
can make relationships with a single or more than one entity of set 2. Or we can also
describe it as from set 2, more than one entity can make a relationship with only one entity
of set 1.

One to one cardinality is the subset of One-to-many Cardinality. It can be represented

by 1: M.

For Example, in a hospital, there can be various compounders, so the relationship

between the hospital and compounders can be mapped through One-to-many Cardinality.
Many to Many Cardinalities:
In many, many cardinalities mapping, there can be one or more than one entity that can
associate with one or more than one entity of set 2. In the same way from the end of set
2, one or more than one entity can make a relation with one or more than one entity of set
1.

It is represented by M: N or N: M.

One to one cardinality, One to many cardinalities, and Many to one cardinality is the subset
of the many to many cardinalities.

For Example, in a college, multiple students can work on a single project, and a single
student can also work on multiple projects. So, the relationship between the project and
the student can be represented by many to many cardinalities.
What is a Hierarchical Data Model?
The hierarchical data model is the oldest type of the data model. It was
developed by IBM in 1968. It organizes data in a tree-like structure.
Hierarchical model consists of the following:
 It contains nodes which are connected by branches.
 The topmost node is called the root node.
 If there are multiple nodes appear at the top level, then these can be
called root segments.
 Each node has exactly one parent.
 One parent may have many children.
In the above figure, Electronics is the root node which has two children i.e.
Televisions and Portable Electronics. These two has further children for
which they act as parent. For example: Television has children as Tube,
LCD and Plasma, for these three Television act as parent. It follows one
to many relationship.

Advantages of the Hierarchical Data Model

 Because of its tree form, it is easy to grasp.

 Retrieving data in a one-to-many connection is efficient.

Disadvantages of the Hierarchical Data Model

 Inflexibility in reorganizing data.

 Accessing complicated data structures may be challenging.
 Redundant data storage, which might cause anomalies and
inconsistencies.
What is a Network Data Model?

It is the advance version of the hierarchical data model. To organize data it

uses directed graphs instead of the tree-structure. In this child can have
more than one parent. It uses the concept of the two data structures i.e.
Records and Sets.

In the above figure, Project is the root node which has two children i.e.
Project 1 and Project 2. Project 1 has 3 children and Project 2 has 2
children. Total there are 5 children i.e Department A, Department B and
Department C, they are network related children as we said that this model
can have more than one parent. So, for the Department B and Department
C have two parents i.e. Project 1 and Project 2.
Advantages of the Network Data Model

 Because of its numerous parent ties, it is more adaptable than the

hierarchical approach.
 Ideal for managing intricate, many-to-many connections.

Disadvantages of the Network Data Model

 Increased complexity in database design and management.

 Requires complex programming in order to manage and work with
data.

What is a Relational Data Model?

The relational data model was developed by E.F. Codd in 1970. There are
no physical links as they are in the hierarchical data model. Following are
the properties of the relational data model:
 Data is represented in the form of table only.
 It deals only with the data not with the physical structure.
 It provides information regarding metadata.
 At the intersection of row and column there will be only one value for
the tuple.
 It provides a way to handle the queries with ease.

Advantages of the Relational Data Model

 High data independence and flexibility.
 Offers robust and user-friendly querying features.
 Removes duplication by use of normalization.

Disadvantages of the Relational Data Model

 For certain kinds of straightforward data retrieval tasks, they may not
perform as well as hierarchical models.
 Demands a deeper comprehension of SQL and normalization
principles.

DDL (Data Definition Language):

DDL or Data Definition Language actually consists of the SQL commands

that can be used to define the database schema. It simply deals with
descriptions of the database schema and is used to create and modify the
structure of database objects in the database.
DDL is a set of SQL commands used to create, modify, and delete
database structures but not data. These commands are normally not used
by a general user, who should be accessing the database via an
application.
List of DDL Commands:
Here are all the main DDL (Data Definition Language) commands along
with their syntax:

Command Description Syntax

Create database or its

CREATE TABLE table_name
objects (table, index, (column1 data_type, column2
CREATE
function, views, store data_type, ...);
procedure, and triggers)

Delete objects from the DROP TABLE table_name;

DROP
database

ALTER TABLE table_name ADD

Alter the structure of the COLUMN column_name
ALTER
database data_type;

Remove all records from TRUNCATE TABLE table_name;

TRUNCATE
a table, including all
 Command Description Syntax

spaces allocated for the

records are removed

Add comments to the COMMENT 'comment_text' ON

COMMENT TABLE table_name;
data dictionary

Rename an object RENAME TABLE old_table_name

RENAME TO new_table_name;
existing in the database

DML (Data Manipulation Language):

The SQL commands that deal with the manipulation of data present in the
database belong to DML or Data Manipulation Language and this includes
most of the SQL statements.
List of DML commands
Here are all the main DML (Data Manipulation Language) commands
along with their syntax:
Command Description Syntax

INSERT INTO table_name (column1,

Insert data into a column2, ...) VALUES (value1, value2,
INSERT
table ...);

Update existing
UPDATE table_name SET column1 = value1,
UPDATE data within a column2 = value2 WHERE condition;
table

Delete records
DELETE from a database DELETE FROM table_name WHERE condition;
table

Table control LOCK TABLE table_name IN lock_mode;

LOCK
concurrency

Call a PL/SQL or
CALL JAVA CALL procedure_name(arguments);
subprogram
Command Description Syntax

Describe the
EXPLAIN EXPLAIN PLAN FOR SELECT * FROM
access path to table_name;
PLAN
data

DQL (Data Query Language):

DQL statements are used for performing queries on the data within schema
objects. The purpose of the DQL Command is to get some schema relation
based on the query passed to it
When a SELECT is fired against a table or tables the result is compiled into
a further temporary table, which is displayed or perhaps received by the
program i.e. a front-end.
DQL Command
There is only one DQL command in SQL i.e.
Command Description Syntax

SELECT column1, column2,

It is used to retrieve data ...FROM table_name WHERE
SELECT
from the database condition;
How to Draw an Entity Relation Diagram (ERD)
A step-by-step process to draw an entity relation diagram (ERD) is:
Step 1: Identifying Entities
Determine the main objects you want to represent in the database. Eg, “students”,
“courses”, or “products”.

Step 2: Defining Attributes

Identify the properties (attributes) of properties of each entity. These attributes provide
more details about an entity.

Step 3: Specifying Relationships

Create relationships between entities to specify how entities interact with each other.
Relationships are verbs like “teaches”, “studies”, or “sells”.

Step 4: Drawing Entities

Draw entities as rectangle and write the name.

Step 5: Adding Attributes

To add attributes of a entity write attributes inside the rectangle or connect them with
lines.

Step 6: Connecting Entities

Draw lines between the related entities to represent their connection.

Step 7: Specifying Cardinality

Indicate the minimum and maximum number of relationship instances associated with an
entity using notations like crow’s foot.

Step 8: Organizing ER Diagram

Organize all entities and relationships in a clean way for better readability and
understanding.

Draw Entity Relationship Diagram Example

After learning the steps of how to draw an enitity relationship diagram, we will create a
demo ER diagram.
Let’s take an example of ER diagram for a bank through which we can learn how to design
an ER and understand all the required methods.
Entity Relationship Diagram for BANK
We will follow the steps mentioned above, to draw entity relationship diagram for bank.
Defining Entities
A thing in the real world with an independent existence. It is may be an object with physical
existence (ex: house, person) or with a conceptual existence (ex: course, job). The are
represented by rectangle.
Entities for Bank are:
Bank, Branch, Employee, customer, loan, account.
Adding Attributes
Attributes are the kind of properties that describe the entities. They are represented
by ovals.
Attributes for Bank are:
 For Bank Entity the Attributes are Bname, code.
 For Branch Entity the Attributes are Blocation, Bname.
 For Employee Entity the Attributes are Eid, Designation, salary.
 For Customer Entity the Attributes are Cid, Cname, Address, DOB.
 For Loan Entity the Attributes are Loan_no, amount, rate.
 For Account Entity the Attributes are acc_no, type.
Establishing Relationships
Entities have some relationships with each other. Relationships define how entities are
associated with each other.
Let’s Establishing Relationships between them are:
 The Bank has branches.
 The Branch provides loan.
 The Employee works in branch.
 The Branch contains customers.
 The Customers has account.
 The Branch maintains account.
 The Customer avails loan.

Specify cardinality for Bank:

 Bank and branch has One to Many relationship (a bank has multiple branches).
 Branch and loan has also One to
Many
 relationship (a branch can provide many loans).
 Branch and employee has One to Many relationship (one branch has many employees).
 Branch and account has One to Many relationship (one branch has many accounts).
 Branch and customer has Many to Many relationship (multiple branches have multiple
customers).
 Customer and account has Many to Many relationship (multiple customers have
multiple accounts).
 Customer and loan has Many to Many relationships(multiple customers have multiple
loans)
 Identify Primary Keys
 Primary keys are the unique identifier for each record in database table. It is
denoted by an underline under the attribute name.
 The Primary key of Bank is code.
 The Primary key of Branch is branch_code.
 The Primary key of Employee is Eid.
 The Primary key of Customer is Cid.
 The Primary key of Loan is loan_no.
 The Primary key of Account is acc_no.
 Final ER Diagram
The below diagram is our final entity relationship diagram for bank with all entities,
their attributes and the relationship between them with the PRIMARY KEY and Cardinality
ratio.
Hospital ER Model:
This is an ER model of a Hospital. The entities are represented in rectangular
boxes and are Patient, Tests and Doctor.

Each of these entities have their respective attributes which are −

 Patients - ID(primary key), name, age,visit_date

 Tests- Name(primary key), date, result
 Doctor- ID(primary key), name, specialization
Company ER Model
The entities in this ER model are Employee, Department and Project. These
entities have the following attributes −

 Employee - ENO(Primary Key) , Name, Salary

 Department - DNO(Primary key), Name, Locations
 Project - PNO(Primary key), Name
University Management System:
Introduction of Relational Algebra:
Relational Algebra is a procedural query language. Relational
algebra mainly provides a theoretical foundation for relational
databases and SQL. The main purpose of using Relational Algebra is
to define operators that transform one or more input relations into an
output relation.

Fundamental Operators:
1. Selection(σ)
2. Projection(π)
3. Union(U)
4. Set Difference(-)
5. Set Intersection(∩)
6. Rename(ρ)
7. Cartesian Product(X)

1. Selection (σ): It is used to select required tuples of the relations.

Example:
A B C

1 2 4

2 2 3

3 2 3

4 3 4

For the above relation, σ(c>3)R will select the tuples which have c more
than 3.

A B C

1 2 4
A B C

4 3 4

Note: The selection operator only selects the required tuples but does not
display them. For display, the data projection operator is used.

2. Projection(π): It is used to project required column data from a relation.

Example: Consider Table 1. Suppose we want columns B and C from
Relation R.

π(B,C)R will show following columns.

B C

2 4

2 3

3 4

Note: By Default, projection removes duplicate data.

3. Union(U): Union operation in relational algebra is the same as union

operation in set theory.
Example:

FRENCH
Student_Name Roll_Number

Ram 01

Mohan 02

Vivek 13
Student_Name Roll_Number

Geeta 17

GERMAN
Student_Name Roll_Number

Vivek 13

Geeta 17

Shyam 21

Rohan 25

Consider the following table of Students having different optional subjects

in their course.
π(Student_Name)FRENCH U π(Student_Name)GERMAN

Student_Name

Ram

Mohan

Vivek

Geeta

Shyam

Rohan
Note: The only constraint in the union of two relations is that both relations
must have the same set of Attributes.

4. Set Difference(-): Set Difference in relational algebra is the same set

difference operation as in set theory.
Example: From the above table of FRENCH and GERMAN, Set Difference
is used as follows
π(Student_Name)FRENCH - π(Student_Name)GERMAN

Student_Name

Ram

Mohan

Note: The only constraint in the Set Difference between two relations is that
both relations must have the same set of Attributes.

5. Set Intersection (∩): Set Intersection in relational algebra is the same

set intersection operation in set theory.
Example: From the above table of FRENCH and GERMAN, the Set
Intersection is used as follows
π(Student_Name)FRENCH ∩ π(Student_Name)GERMAN
Student_Name

Vivek

Geeta

Note: The only constraint in the Set Difference between two relations is that
both relations must have the same set of Attributes.

6. Rename(ρ): Rename is a unary operation used for renaming attributes

of a relation.
ρ(a/b)R will rename the attribute 'b' of the relation by 'a'.

7. Cross Product(X): Cross-product between two relations. Let’s say A

and B, so the cross product between A X B will result in all the attributes of
A followed by each attribute of B. Each record of A will pair with every record
of B.
Example:
 A
Name Age Sex

Ram 14 M

Sona 15 F

Kim 20 M

B
ID Course

1 DS

2 DBMS

A
XB
Name Age Sex ID Course

Ram 14 M 1 DS

Ram 14 M 2 DBMS

Sona 15 F 1 DS

Sona 15 F 2 DBMS

Kim 20 M 1 DS

Kim 20 M 2 DBMS
Note: If A has ‘n’ tuples and B has ‘m’ tuples then A X B will have ‘ n*m ‘
tuples.

Derived Operators
These are some of the derived operators, which are derived from the
fundamental operators.
1. Natural Join(⋈)
2. Conditional Join

1. Natural Join(⋈): Natural join is a binary operator. Natural join between

two or more relations will result in a set of all combinations of tuples where
they have an equal common attribute.
Example:

EMP
Name ID Dept_Name

A 120 IT

B 125 HR

C 110 Sales

D 111 IT

DEPT
Dept_Name Manager

Sales Y

Production Z

IT A

Natural join between EMP and DEPT with condition :

EMP.Dept_Name = DEPT.Dept_Name

EMP ⋈ DEPT
Name ID Dept_Name Manager

A 120 IT A

C 110 Sales Y

D 111 IT A

2. Conditional Join: Conditional join works similarly to natural join. In

natural join, by default condition is equal between common attributes while
in conditional join we can specify any condition such as greater than, less
than, or not equal.
Example:

R
ID Sex Marks

1 F 45

2 F 55

3 F 60

S
ID Sex Marks

10 M 20
ID Sex Marks

11 M 22

12 M 59

Join between R and S with condition R.marks >= S.marks

R.ID R.Sex R.Marks S.ID S.Sex S.Marks

1 F 45 10 M 20

1 F 45 11 M 22

2 F 55 10 M 20

2 F 55 11 M 22

3 F 60 10 M 20

3 F 60 11 M 22

3 F 60 12 M 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
satisfy desirable properties. Normalization is a process of decomposing the
relations into relations with fewer attributes.

What is Normalization?
○ 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.

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:

○ 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.
○ Updation 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.

Following are the various types of Normal forms:

Normal Form Description

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
○ Normalization helps to minimize data redundancy.
○ Greater overall database organization.
○ Data consistency within the database.
○ Much more flexible database design.
○ Enforces the concept of relational integrity.

Disadvantages of Normalization
○ You cannot start building the database before knowing what the user
needs.
○ The performance degrades when normalizing the relations to higher
normal forms, i.e., 4NF, 5NF.
○ It is very time-consuming and difficult to normalize relations of a higher
degree.
 ○ Careless decomposition may lead to a bad database design, leading to
serious problems.

First Normal Form (1NF)

○ A relation will be 1NF if it contains an atomic value.
○ It states that an attribute of a table cannot hold multiple values. It must
hold only single-valued attribute.
○ 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)

○ In the 2NF, relational must be in 1NF.
○ 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

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)

○ A relation will be in 3NF if it is in 2NF and not contain any transitive
partial dependency.
○ 3NF is used to reduce the data duplication. It is also used to achieve the
data integrity.
○ 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.

Example:
EMPLOYEE_DETAIL table:

EMP_ID EMP_NA EMP_ZIP EMP_STA EMP_CIT

ME TE Y

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

1.
Super key in the table above:
​ {EMP_ID}, {EMP_ID, EMP_NAME}, {EMP_ID, EMP_NAME,
EMP_ZIP}....so on
2. 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

3.
EMPLOYEE_ZIP table:
 EMP_ZIP EMP_STATE EMP_CITY

201010 UP Noida

02228 US Boston

60007 US Chicago

06389 UK Norwich

462007 MP Bhopal

Boyce Codd normal form (BCNF)

○ BCNF is the advance version of 3NF. It is stricter than 3NF.
○ A table is in BCNF if every functional dependency X → Y, X is the super
key of the table.
○ 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_COUN EMP_DEPT DEPT_TYPE EMP_DEPT_

TRY 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:

​ EMP_ID → EMP_COUNTRY
​ 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

EMP_DEPT_MAPPING table:

EMP_ID EMP_DEPT

D394 283

D394 300

D283 232

D283 549

Functional dependencies:

​ EMP_ID → EMP_COUNTRY
​ 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.