DBMS Notes (New)

DBMS
Database Management System

Database, the database is a collection of inter-related data which is used to retrieve,
insert, and delete the data efficiently. It is also used to organize the data in the form of a
table, schema, views, and reports, etc.
For example: The college Database organizes the data about the admin, staff, students,
and faculty etc.
Using the database, you can easily retrieve, insert, and delete the information. Database
management system is software that is used to manage the database.
Drawbacks of File system

• Data redundancy: Data redundancy refers to the duplication of data, let’s say we
are managing the data of a college where a student is enrolled for two courses, the
same student details in such case will be stored twice, which will take more storage
than needed. Data redundancy often leads to higher storage costs and poor access
time.
• Data inconsistency: Data redundancy leads to data inconsistency, let’s take the
same example that we have taken above, a student is enrolled for two courses and
we have student address stored twice, now let’s say student requests to change his
address, if the address is changed at one place and not on all the records then this
can lead to data inconsistency.
• Data Isolation: Because data are scattered in various files, and files may be in
different formats, writing new application programs to retrieve the appropriate data
is difficult.
• Dependency on application programs: Changing files would lead to change in
application programs.
• Atomicity issues: Atomicity of a transaction refers to “All or nothing”, which
means either all the operations in a transaction executes or none.
1
S Sathyanarayana, CSE, JNNCE, 577204.
DBMS
For example: Let’s say Steve transfers 100$ to Smith’s account. This transaction
consists multiple operations such as debit 100$ from Steve’s account, credit 100$ to
Smith’s account. Like any other device, a computer system can fail let’s say it fails
after first operation then in that case Steve’s account would have been debited by
100$ but the amount was not credited to Smith’s account, in such case the rollback
of operation should occur to maintain the atomicity of transaction. It is difficult to
achieve atomicity in file processing systems.
• Data Security: Data should be secured from unauthorized access, for example a
student in a college should not be able to see the payroll details of the teachers, such
kind of security constraints are difficult to apply in file processing systems.
Advantage of DBMS over file system
There are several advantages of Database management system over file system. Few of
them are as follows:
• No redundant data: Redundancy removed by data normalization. No data

duplication saves storage and improves access time.
• Data Consistency and Integrity: As we discussed earlier the root cause of data
inconsistency is data redundancy, since data normalization takes care of the data
redundancy, data inconsistency also been taken care of as part of it
• Data Security: It is easier to apply access constraints in database systems so that
only authorized user can access the data. Each user has a different set of access thus
data is secured from the issues such as identity theft, data leaks and misuse of data.
• Privacy: Limited access means privacy of data.
• Easy access to data – Database systems manages data in such a way so that the data
is easily accessible with fast response times.
• Easy recovery: Since a database system keeps the backup of data, it is easier to do a
full recovery of data in case of a failure.
• Flexible: Database systems are more flexible than file processing systems.
2
DBMS
What is the need of DBMS?

Database systems are basically developed for large amount of data. When dealing with
huge amount of data, there are two things that require optimization: Storage of
data and retrieval of data.
Disadvantages of DBMS:
• DBMS implementation cost is high compared to the file system

• Complexity: Database systems are complex to understand
• Performance: Database systems are generic, making them suitable for various
applications. However, this feature affect their performance for some applications
Purpose of Database Systems
The main purpose of database systems is to manage the data. Consider a university that
keeps the data of students, teachers, courses, books etc. To manage this data we need to
store this data somewhere where we can add new data, delete unused data, update
outdated data, retrieve data, to perform these operations on data we need a Database
management system that allows us to store the data in such a way so that all these
operations can be performed on the data efficiently.
Database Applications – DBMS
Applications where we use Database Management Systems are:
• Telecom: There is a database to keeps track of the information regarding calls

made, network usage, customer details etc. Without the database systems it is hard
to maintain that huge amount of data that keeps updating every millisecond.
• Industry: Where it is a manufacturing unit, warehouse or distribution center, each
one needs a database to keep the records of ins and outs. For example, distribution
center should keep a track of the product units that supplied into the center as well
3
DBMS
as the products that got delivered out from the distribution center on each day; this is
where DBMS comes into picture.
• Banking System: For storing customer info, tracking day to day credit and debit
transactions, generating bank statements etc. All this work has been done with the
help of Database management systems.
• Sales: To store customer information, production information and invoice details.
• Airlines: To travel though airlines, we make early reservations; this reservation
information along with flight schedule is stored in database.
• Education sector: Database systems are frequently used in schools and colleges to
store and retrieve the data regarding student details, staff details, course details,
exam details, payroll data (Payroll is a list of employees who get paid by the
company), attendance details, fees details etc. There is a hell lot amount of inter-
related data that needs to be stored and retrieved in an efficient manner.
• Online shopping: You must be aware of the online shopping websites such as
Amazon, Flipkart etc. These sites store the product information, your addresses and
preferences, credit details and provide you the relevant list of products based on
your query. All this involves a Database management system.
DBMS Architecture
Database management systems architecture will help us understand the components of
database system and the relation among them.
The architecture of DBMS depends on the computer system on which it runs. For
example, in a client-server DBMS architecture, the database systems at server machine
can run several requests made by client machine. We will understand this communication
with the help of diagrams.
Types of DBMS Architecture

There are three types of DBMS architecture:
4
DBMS
1. Single tier architecture

2. Two tier architecture
3. Three tier architecture
1. Single tier architecture

In this type of architecture, the database is readily available on the client machine; any request
made by client does not require a network connection to perform the action on the database.
For example, let’s say you want to fetch the records of employee from the database and the
database is available on your computer system, so the request to fetch employee details will be
done by your computer and the records will be fetched from the database by your computer as
well. This type of system is generally referred as local database system.
2. Two tier architecture

In two-tier architecture, the Database system is present at the server machine and the DBMS
application is present at the client machine, these two machines are connected with each other
through a reliable network as shown diagram.
Whenever client machine makes a request to access the database present at server using a query
language like sql, the server perform the request on the database and returns the result back to the
client. The application connection interface such as JDBC, ODBC are used for the interaction
between server and client.
3. Three tier architecture

In three-tier architecture, another layer is present between the client machine and server machine.
In this architecture, the client application does not communicate directly with the database
systems present at the server machine, rather the client application communicates with server
application and the server application internally communicates with the database system present
at the server.
5
DBMS
Two tier architecture
DBMS Three Level Architecture Diagram
6
DBMS
This architecture has three levels:

1. External level
2. Conceptual level
3. Internal level
1. External level
It is also called view level. The reason this level is called “view” is because several users
can view their desired data from this level which is internally fetched from database with
the help of conceptual and internal level mapping.
The user doesn’t need to know the database schema details such as data structure, table
definition etc. user is only concerned about data which is what returned back to the view
level after it has been fetched from database (present at the internal level).
7
DBMS
External level is the “top level” of the Three Level DBMS Architecture.
2. Conceptual level
It is also called logical level. The whole design of the database such as relationship
among data, schema of data etc. are described in this level.
Database constraints and security are also implemented in this level of architecture. This
level is maintained by DBA (database administrator).
3. Internal level
This level is also known as physical level. This level describes how the data is actually
stored in the storage devices. This level is also responsible for allocating space to the
data. This is the lowest level of the architecture.
View of Data in DBMS

Abstraction is one of the main features of database systems. Hiding irrelevant details
from user and providing abstract view of data to users, helps in easy and efficient user-
database interaction. We discussed the three levels of DBMS architecture, the top level
of that architecture is “view level”. The view level provides the “view of data” to the
users and hides the irrelevant details such as data relationship, database
schema, constraints, security etc. from the user.
DBMS Schema
Definition of schema: Design of a database is called the schema. Schema is of three
types: Physical schema, logical schema and view schema.
8
DBMS
For example: In the following diagram, we have a schema that shows the relationship
between three tables: Course, Student and Section. The diagram only shows the design
of the database, it does not show the data present in those tables. Schema is only a
structural view (design) of a database as shown in the diagram below.
The design of a database at physical level is called physical schema, how the data stored
in blocks of storage is described at this level.
Design of database at logical level is called logical schema, programmers and database
administrators work at this level, however the internal details such as implementation of
data structure is hidden at this level (available at physical level).
Design of database at view level is called view schema. This generally describes end user
interaction with database systems.
9
DBMS
DBMS Instance
Definition of instance: The data stored in database at a particular moment of time is
called instance of database. Database schema defines the variable declarations in tables
that belong to a particular database; the value of these variables at a moment of time is
called the instance of that database.
For example, let’s say we have a single table student in the database, today the table has
100 records, and so today the instance of the database has 100 records. Let us say we are
going to add another 100 records in this table by tomorrow so the instance of database
tomorrow will have 200 records in table. In short, at a particular moment the data stored
in database is called the instance that changes over time when we add or delete data from
the database.
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. Let’s have a
look at a simple ER diagram to understand this concept.
10
DBMS
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.
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
11
DBMS
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.
12
DBMS
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.
The entity set which does not have sufficient attributes to form a primary key is called
as Weak entity set. An entity set that has a primary key is called as Strong entity set.
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
13
DBMS
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.
14
DBMS
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
15
DBMS
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.
16
DBMS
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 student can be
assigned to many projects and a project can be assigned to many students.
Total Participation of an Entity set

A Total participation of an entity set represents that each entity in entity set must have at
least one relationship in a relationship set. For example: In the diagram each college must
have at-least one associated Student.
17
DBMS
ACID properties in DBMS

To ensure the integrity of data during a transaction, the database system maintains the
following properties. These properties are widely known as ACID properties:
• Atomicity: This property ensures that either all the operations of a transaction
reflect in database or none. Let’s take an example of banking system to understand
this: Suppose Account A has a balance of 400$ & B has 700$. Account A is
transferring 100$ to Account B. This is a transaction that has two operations (a)
Debiting 100$ from A’s balance (b) Crediting 100$ to B’s balance. Let’s say first
operation passed successfully while second failed, in this case A’s balance would be
300$ while B would be having 700$ instead of 800$. This is unacceptable in a
banking system. Either the transaction should fail without executing any of the
operation or it should process both the operations. The Atomicity property ensures
that.
• Consistency: To preserve the consistency of database, the execution of transaction
should take place in isolation (that means no other transaction should run
concurrently when there is a transaction already running). For example account A is
having a balance of 400$ and it is transferring 100$ to account B & C both. So we
have two transactions here. Let’s say these transactions run concurrently and both
the transactions read 400$ balance, in that case the final balance of A would be 300$
instead of 200$. This is wrong. If the transaction were to run in isolation, then the
second transaction would have read the correct balance 300$ (before debiting 100$)
once the first transaction went successful.
• Isolation: For every pair of transactions, one transaction should start execution only
when the other finished execution. I have already discussed the example of Isolation
in the Consistency property above.
• Durability: Once a transaction completes successfully, the changes it has made into
the database should be permanent even if there is a system failure. The recovery-
management component of database systems ensures the durability of transaction.
18
DBMS
Data Abstraction in DBMS

Database systems are made-up of complex data structures. The developers hide internal
irrelevant details from users. This process of hiding irrelevant details from user is called
data abstraction.
We have three levels of abstraction

Physical level: This is the lowest level of data abstraction. It describes how data is
actually stored in database. You can get the complex data structure details at this level.
Logical level: This is the middle level of 3-level data abstraction architecture. It describes
what data is stored in database.
View level: Highest level of data abstraction. This level describes the user interaction
with database system.
Example: Let’s say we are storing customer information in a customer table. At physical
level these records can be described as blocks of storage (bytes, gigabytes, terabytes etc.)
in memory. These details are often hidden from the programmers.
At the logical level these records can be described as fields and attributes along with their
data types, their relationship among each other can be logically implemented. The
19
DBMS
programmers generally work at this level because they are aware of such things about
database systems.
At view level, user just interact with system with the help of GUI and enter the details at
the screen, they are not aware of how the data is stored and what data is stored; such
details are hidden from them.
Data models in DBMS

Data Model is a logical structure of Database. It describes the design of database to
reflect entities, attributes, relationship among data, constrains etc.
Object based logical Models – Describe data at the conceptual and view levels.
1. E-R Model
2. Object oriented Model
Record based logical Models – Like Object based model, they also describe data at the
conceptual and view levels. These models specify logical structure of database with
records, fields and attributes.
1. Relational Model
2. Hierarchical Model
3. Network Model
Relational model in DBMS

In relational model, the data and relationships are represented by collection of inter-
related tables. Each table is a group of column and rows, where column represents
attribute of an entity and rows represents records.
Sample relationship Model: Student table with 3 columns and four records.
Table: Student
20
DBMS
Stu_Id Stu_Name Stu_Age
111 Ashish 23
123 Saurav 22
169 Amith 24
234 Sumith 26
Table: Course
Stu_Id Course_Id Course_Name
111 C01 Science

111 C02 DBMS
169 C22 Java
169 C39 Computer Networks
Here Stu_Id, Stu_Name & Stu_Age are attributes of table Student and Stu_Id, Course_Id
& Course_Name are attributes of table Course. The rows with values are the records
(commonly known as tuples).
DBMS Generalization
Generalization is a process in which the common attributes of more than one entities
form a new entity. This newly formed entity is called generalized entity.
Generalization Example
Let’s say we have two entities Student and Teacher.
Attributes of Entity Student are: Name, Address & Grade
Attributes of Entity Teacher are: Name, Address & Salary
The ER diagram before generalization looks like this:
21
DBMS
These two entities have two common attributes: Name and Address, we can make a
generalized entity with these common attributes. Let’s have a look at the ER model after
generalization.
The ER diagram after generalization:

We have created a new generalized entity Person and this entity has the common
attributes of both the entities. As you can see in the following ER diagram that after the
generalization process the entities Student and Teacher only has the specialized
attributes Grade and Salary respectively and their common attributes (Name & Address)
are now associated with a new entity Person which is in the relationship with both the
entities (Student & Teacher).
22
DBMS
Note:
1. Generalization uses bottom-up approach where two or more lower level entities
combine together to form a higher-level new entity.
2. The new generalized entity can further combine together with lower level entity to
create a further higher-level generalized entity.
DBMS Specialization
Specialization is a process in which an entity is divided into sub-entities. You can think
of it as a reverse process of generalization, in generalization two entities combine
together to form a new higher level entity. Specialization is a top-down process.
The idea behind Specialization is to find the subsets of entities that have few distinguish
attributes. For example – Consider an entity employee which can be further classified as
sub-entities Technician, Engineer & Accountant because these sub entities have some
distinguish attributes.
23
DBMS
Specialization Example
In the above diagram, we can see that we have a higher-level entity “Employee” which
we have divided in sub entities “Technician”, “Engineer” & “Accountant”. All of these
are just an employee of a company; however their role is completely different and they
have few different attributes. Just for the example, I have shown that Technician handles
service requests, Engineer works on a project and Accountant handles the credit & debit
details. All of these three employee types have few attributes common such as name &
salary which we had left associated with the parent entity “Employee” as shown in the
above diagram.
DBMS Aggregation
24
DBMS
Aggregation is a process in which a single entity alone is not able to make sense in a
relationship so the relationship of two entities acts as one entity. I know it sounds
confusing but don’t worry the example we will take, will clear all the doubts.
In real world, we know that a manager not only manages the employee working under
them but he has to manage the project as well. In such scenario if entity “Manager”
makes a “manages” relationship with either “Employee” or “Project” entity alone then it
will not make any sense because he has to manage both. In these cases, the relationship of
two entities acts as one entity. In our example, the relationship “Works-On” between
“Employee” & “Project” acts as one entity that has a relationship “Manages” with the
entity “Manager”.
Constraints in DBMS
Constraints enforce limits to the data or type of data that can be inserted/updated/deleted
from a table. The whole purpose of constraints is to maintain the data integrity during an
25
DBMS
update/delete/insert into a table. Here we will learn several types of constraints that can
be created in RDBMS.
Types of constraints
• NOT NULL
• UNIQUE
• DEFAULT
• CHECK
• Key Constraints – PRIMARY KEY, FOREIGN KEY
• Domain constraints
• Mapping constraints
NOT NULL:
NOT NULL constraint makes sure that a column does not hold NULL value. When we
do not provide value for a particular column while inserting a record into a table, it takes
NULL value by default. By specifying NULL constraint, we can be sure that a particular
column(s) cannot have NULL values.
How to specify the NULL constraint while creating table

Here I am creating a table “STUDENTS”. I have specified NOT NULL constraint for
columns ROLL_NO, STU_NAME and STU_AGE which means you must provide the
value for these three fields while inserting/updating records in this table. It enforces these
column(s) not to accept null values.
Example:
CREATE TABLE STUDENTS (

ROLL_NO INT NOT NULL,
STU_NAME VARCHAR (35) NOT NULL,
STU_AGE INT NOT NULL,
STU_ADDRESS VARCHAR (235),
PRIMARY KEY (ROLL_NO)
);
26
DBMS
Specify the NULL constraint for already existing table

In the above section we learnt how to specify the NULL constraint while creating a table.
However, we can specify this constraint on an already present table also. For this we need
to use ALTER TABLE statement.
ALTER TABLE STUDENTS

MODIFY STU_ADDRESS VARCHAR (235) NOT NULL;
After this STU_ADDRESS column will not accept any null values.
UNIQUE:
UNIQUE Constraint enforces a column or set of columns to have unique values. If a

column has a unique constraint, it means that particular column cannot have duplicate
values in a table.

STU_NAME VARCHAR (35) NOT NULL UNIQUE,
STU_ADDRESS VARCHAR (35) UNIQUE,
);
UNIQUE Constraint in SQL

Syntax:
CREATE TABLE <table_name>

(
<column_name1> <data_type> UNIQUE,
<column_name2> <data_type>,
....
....
);
27
DBMS
Example:
Here we are setting up the UNIQUE Constraint for two columns: STU_NAME &
STU_ADDRESS. Which means these two columns cannot have duplicate values.
Note: STU_NAME column has two constraints (NOT NULL and UNIQUE both) setup.

);
Set UNIQUE Constraint on a already created table

For single column and without constraint naming:
Syntax:
ALTER TABLE <table_name>

ADD UNIQUE (<column_name>);
Example:

ADD UNIQUE (STU_NAME);
For multiple columns and with constraint naming:
Syntax:

ADD CONSTRAINT <constraint_name> UNIQUE (<column_name1>,
<column_name2>,...);
Example:
28
DBMS

ADD CONSTRAINT stu_Info UNIQUE (STU_NAME, STU_ADDRESS);
How to drop a UNIQUE Constraint
Syntax:

DROP CONSTRAINT <constraint_name>;
Example:

DROP CONSTRAINT stu_Info;
DEFAULT:
The DEFAULT constraint provides a default value to a column when there is no value
provided while inserting a record into a table.
CREATE TABLE STUDENT (

EXAM_FEE INT DEFAULT 10000,
);
What if we want to set this constraint on an already existing table? For this we can
ALTER Table statement like this:
Syntax:

MODIFY <column_name> <column_data_type> DEFAULT <default_value>;
29
DBMS
Example:

MODIFY EXAM_FEE INT DEFAULT 10000;
This way we can set constraint on a already created table.
How to drop DEFAULT Constraint
In the above sections, we have learnt the ways to set Constraint. Here we will see how to
drop (delete) a Constraint:
Syntax:

ALTER COLUMN <column_name> DROP DEFAULT;
Example:
Let’s say we want to drop the constraint from STUDENTS table, which we have created
in the above sections. We can do it like this.

ALTER COLUMN EXAM_FEE DROP DEFAULT;
CHECK:
This constraint is used for specifying range of values for a particular column of a table.
When this constraint is being set on a column, it ensures that the specified column must
have the value falling in the specified range.

ROLL_NO INT NOT NULL CHECK (ROLL_NO >1000),
30
DBMS
EXAM_FEE INT DEFAULT 10000,

);
In the above example we have set the check constraint on ROLL_NO column of
STUDENT table. Now, the ROLL_NO field must have the value greater than 1000.
Key constraints:
PRIMARY KEY:
Primary key uniquely identifies each record in a table. It must have unique values and
cannot contain nulls. In the below example the ROLL_NO field is marked as primary
key, that means the ROLL_NO field cannot have duplicate and null values.

);
FOREIGN KEY:
Foreign keys are the columns of a table that points to the primary key of another table.
They act as a cross-reference between tables.
For example:
In the below example the Stu_Id column in Course_enrollment table is a foreign key as
it points to the primary key of the Student table.
31
DBMS
Course_enrollment table:
Course_Id Stu_Id
C01 101
C02 102
C03 101
C05 102
C06 103
C07 102
Student table:
101 Chaitanya 22
102 Arya 26
103 Bran 25
104 Jon 21
Note: Practically, the foreign key has nothing to do with the primary key tag of another
table, if it points to a unique column (not necessarily a primary key) of another table then
too, it would be a foreign key. So, a correct definition of foreign key would be: Foreign
keys are the columns of a table that points to the candidate key of another table.
Domain constraints:
Each table has certain set of columns and each column allows a same type of data, based
on its data type. The column does not accept values of any other data type.
Constraints are the restrictions on the actual values in a database.

When we have to insert into the database, we should impose some constraints on those
values.
32
DBMS
Domain constraints are user defined data type and we can define them like this:
Domain Constraint = data type + Constraints (NOT NULL / UNIQUE / PRIMARY KEY
/ FOREIGN KEY / CHECK / DEFAULT)
A table in DBMS is a set of rows and columns that contain data. Columns in the table
have a unique name, often referred as attributes in DBMS. A domain is a unique set of
values permitted for an attribute in a table. For example, a domain of month-of-year can
accept January, February…. December as possible values, a domain of integers can
accept whole numbers that are negative, positive and zero.
Example:
For example I want to create a table “student_info” with “stu_id” field having value
greater than 100, I can create a domain and table like this:
CREATE DOMAIN stu_id_domain

create domain id_value int
constraint id_test AS INT CHECK (VALUE > 100);
check(value > 100);
OR
create table student_info ( CREATE TABLE student_info (
stu_id id_value PRIMARY KEY, stu_id stu_id_domain,
stu_name varchar(30), -- Other fields of the table
stu_age int );
);
OR
CREATE TABLE student_info (

stu_id INT CHECK (stu_id > 100),
-- Other fields of the table
);
In this example, the CHECK constraint ensures that the value of "stu_id" must be greater
than 100 for any row inserted into the "student_info" table.
33
DBMS
Mapping constraints:
Mapping Cardinality:
One to One: An entity of entity-set A can be associated with at most one entity of entity-
set B and an entity in entity-set B can be associated with at most one entity of entity-set
A.
One to Many: An entity of entity-set A can be associated with any number of entities of
entity-set B and an entity in entity-set B can be associated with at most one entity of
entity-set A.
Many to One: An entity of entity-set A can be associated with at most one entity of
entity-set B and an entity in entity-set B can be associated with any number of entities of
entity-set A.
Many to Many: An entity of entity-set A can be associated with any number of entities
of entity-set B and an entity in entity-set B can be associated with any number of entities
of entity-set A.
We can have these constraints in place while creating tables in database.
Example:
CREATE TABLE Customer (

customer_id int PRIMARY KEY NOT NULL,
first_name varchar(20),
last_name varchar(20)
);
CREATE TABLE Order (

order_id int PRIMARY KEY NOT NULL,
order_details varchar(50),
Buyer_id REFERENCES Customer(customer_id) ON DELETE CASCADE
);
34
DBMS
Assuming, that a customer orders more than once, the above relation represents one to
many relation. Similarly we can achieve other mapping constraints based on the
requirements.
Cardinality in DBMS
In DBMS you may hear cardinality term at two different places and it has two different
meanings as well.
In Context of Data Models:

In terms of data models, cardinality refers to the relationship between two tables.
Relationship can be of four types as we have already seen in Entity relationship:
One to One – A single row of first table associates with single row of second table. For
example, the relationship between person and passport table is one to one because a
person can have only one passport and a passport can be assigned to only one person.
One to Many – A single row of the first table associates with more than one rows of
second table. For example, the relationship between customer and order table is one to
many because a customer can place many orders but a order can be placed by a single
customer alone.
Many to One – Many rows of first table associate with a single row of second table. For
example, relationship between student and university is many to one because a university
can have many students but a student can only study only in single university at a time.
Many to Many – Many rows of first table associate with many rows of second table. For
example, relationship between student and course table is many to many because a
student can take many courses at a time and a course can be assigned to many students.
35
DBMS
In Context of Query Optimization:

In terms of query, the cardinality refers to the uniqueness of a column in a table. The
column with all unique values would be having the high cardinality and the column with
all duplicate values would be having the low cardinality. These cardinality scores helps in
query optimization.
RDBMS Concepts
RDBMS stands for relational database management system. A relational model can be
represented as a table of rows and columns. A relational database has following major
components:
1.Table
2.Record or Tuple
3. Field or Column name or Attribute
4.Domain
5.Instance
6.Schema
7.Keys
NOTE:
A domain is a set of permitted values for an attribute in table. For example, a domain of
month-of-year can accept January, February…December as values, a domain of dates can
accept all possible valid dates etc. We specify domain of attribute while creating a table.
Student_Id Student_Name Student_Addr Student_Age

101 Chaitanya Shimoga 27
An attribute cannot accept values that are outside of their domains. For example, In the
above table “STUDENT”, the Student_Id field has integer domain so that field cannot
accept values that are not integers for example, Student_Id cannot has values like, “First”,
10.11 etc.
36
DBMS
Introduction to Relational algebra & Relational calculus

We need to store and retrieve data from the database, for this purpose we need to
understand the concept of Relational algebra and relational calculus.
Query Language
In simple words, a Language which is used to store and retrieve data from database is
known as query language. For example – SQL
There are two types of query language:

1.Procedural Query language
2.Non-procedural query language
1. Procedural Query language:

In procedural query language, user instructs the system to perform a series of operations
to produce the desired results. Here user’s tells what data to be retrieved from database
and how to retrieve it.
For example – Let’s take a real world example to understand the procedural language,
you are asking your younger brother to make a cup of tea, if you are just telling him to
make a tea and not telling the process then it is a non-procedural language, however if
you are telling the step by step process like switch on the stove, boil the water, add milk
etc. then it is a procedural language.
37
DBMS
2. Non-procedural query language:

In Non-procedural query language, user instructs the system to produce the desired result
without telling the step by step process. Here users tells what data to be retrieved from
database but doesn’t tell how to retrieve it.
Relational Algebra:
Relational algebra is a conceptual procedural query language used on relational model.
Relational Calculus:
Relational calculus is a conceptual non-procedural query language used on relational
model.
NOTE: SQL is a practical implementation of relational algebra and relational calculus.
Relational Algebra, Calculus, RDBMS & SQL:

Relational algebra and calculus are the theoretical concepts used on relational model.
RDBMS is a practical implementation of relational model.
38
DBMS
SQL is a practical implementation of relational algebra and calculus.
What is Relational Algebra in DBMS?

Relational algebra is a procedural query language that works on relational model. The
purpose of a query language is to retrieve data from database or perform various
operations such as insert, update, and delete on the data. When I say that relational
algebra is a procedural query language, it means that it tells what data to be retrieved and
how to be retrieved.
On the other hand relational calculus is a non-procedural query language, which means it
tells what data to be retrieved but doesn’t tell how to retrieve it.
Types of operations in relational algebra

We have divided these operations in two categories:
1. Basic Operations
2. Derived Operations
Basic/Fundamental Operations:
1. Select (σ)
2. Project (∏)
3. Union (∪)
4. Set Difference (-)
5. Cartesian product (X)
6. Rename (ρ)
Derived Operations:
1. Natural Join (⋈)
2. Left, Right, Full outer join (⟕, ⟖, ⟗)
3. Intersection (∩)
4. Division (÷)
Let’s discuss these operations one by one with the help of examples.
39
DBMS
Select Operator (σ)

Select Operator is denoted by sigma (σ) and it is used to find the tuples (or rows) in a
relation (or table) which satisfy the given condition.
If you understand little bit of SQL then you can think of it as a where clause in SQL,
which is used for the same purpose.
Syntax of Select Operator (σ)
σ Condition/Predicate(Relation/Table name)
Select Operator (σ) Example

Table: CUSTOMER
---------------
Customer_Id Customer_Name Customer_City

----------- ------------- -------------
C10100 Steve Agra
C10111 Raghu Agra
C10115 Chaitanya Noida
C10117 Ajeet Delhi
C10118 Carl Delhi
Query:
σ Customer_City="Agra" (CUSTOMER)
Output:

----------- ------------- -------------
C10100 Steve Agra
C10111 Raghu Agra
40
DBMS
Project Operator (∏)

Project operator is denoted by ∏ symbol and it is used to select desired columns (or
attributes) from a table (or relation).
Project operator in relational algebra is similar to the Select statement in SQL.
Syntax of Project Operator (∏)
∏ column_name1, column_name2, ...., column_nameN(table_name)
Project Operator (∏) Example

In this example, we have a table CUSTOMER with three columns, we want to fetch only
two columns of the table, which we can do with the help of Project Operator ∏.
Table: CUSTOMER

----------- ------------- -------------
C10100 Steve Agra
C10111 Raghu Agra
C10117 Ajeet Delhi
C10118 Carl Delhi
Query:
∏ Customer_Name, Customer_City (CUSTOMER)
Output:
Customer_Name Customer_City
------------- -------------
Steve Agra
Raghu Agra
Chaitanya Noida
Ajeet Delhi
41
DBMS
Carl Delhi
Union Operator (∪)

Union operator is denoted by ∪ symbol and it is used to select all the rows (tuples) from
two tables (relations).
Let’s discuss union operator a bit more. Let’s say we have two relations R1 and R2 both
have same columns and we want to select all the tuples (rows) from these relations then
we can apply the union operator on these relations.
Note: The rows (tuples) that are present in both the tables will only appear once in the
union set. In short you can say that there are no duplicates present after the union
operation.
Syntax of Union Operator (∪)
table_name1 ∪ table_name2
Union Operator (∪) Example

Table 1: COURSE
Course_Id Student_Name Student_Id

--------- ------------ ----------
C101 Aditya S901
C104 Aditya S901
C106 Steve S911
C109 Paul S921
C115 Lucy S931
42
DBMS
Table 2: STUDENT
Student_Id Student_Name Student_Age

------------ ---------- -----------
S901 Aditya 19
S911 Steve 18
S921 Paul 19
S931 Lucy 17
S941 Carl 16
S951 Rick 18
Query:
∏ Student_Name (COURSE) ∪ ∏ Student_Name (STUDENT)
Output:
Student_Name
------------
Aditya
Carl
Paul
Lucy
Rick
Steve
Note: As you can see there are no duplicate names present in the output even though we
had few common names in both the tables, also in the COURSE table we had the
duplicate name itself.
Intersection Operator (∩)

Intersection operator is denoted by ∩ symbol and it is used to select common rows
(tuples) from two tables (relations).
43
DBMS
Let’s say we have two relations R1 and R2 both have same columns and we want to
select all those tuples(rows) that are present in both the relations, then in that case we can
apply intersection operation on these two relations R1 ∩ R2.
Note: Only those rows that are present in both the tables will appear in the result set.
Syntax of Intersection Operator (∩)
table_name1 ∩ table_name2
Intersection Operator (∩) Example

Let’s take the same example that we have taken above.
Table 1: COURSE
Course_Id Student_Name Student_Id

--------- ------------ ----------
C101 Aditya S901
C104 Aditya S901
C106 Steve S911
C109 Paul S921
C115 Lucy S931
Table 2: STUDENT
Student_Id Student_Name Student_Age

------------ ---------- -----------
S901 Aditya 19
S911 Steve 18
S921 Paul 19
S931 Lucy 17
S941 Carl 16
S951 Rick 18
Query:
∏ Student_Name (COURSE) ∩ ∏ Student_Name (STUDENT)
44
DBMS
Output:
Student_Name
------------
Aditya
Steve
Paul
Lucy
Set Difference (-)

Set Difference is denoted by – symbol. Let’s say we have two relations R1 and R2 and
we want to select all those tuples(rows) that are present in Relation R1 but not present in
Relation R2, this can be done using Set difference R1 – R2.
Syntax of Set Difference (-)
table_name1 - table_name2
Set Difference (-) Example
Let’s take the same tables COURSE and STUDENT that we have seen above.
Query:
Lets write a query to select those student names that are present in STUDENT table but
not present in COURSE table.
∏ Student_Name (STUDENT) - ∏ Student_Name (COURSE)

Output:
Student_Name
------------
Carl
Rick
45
DBMS
Cartesian product (X)

Cartesian Product is denoted by X symbol. Lets say we have two relations R1 and R2
then the cartesian product of these two relations (R1 X R2) would combine each tuple of
first relation R1 with the each tuple of second relation R2. I know it sounds confusing but
once we take an example of this, you will be able to understand this.
Syntax of Cartesian product (X)
R1 X R2
Cartesian product (X) Example

Table 1: R
Col_A Col_B
----- ------
AA 100
BB 200
CC 300
Table 2: S
Col_X Col_Y
----- -----
XX 99
YY 11
ZZ 101
Query:
Let’s find the cartesian product of table R and S.
RXS
46
DBMS
Output:
Col_A Col_B Col_X Col_Y

----- ------ ------ ------
AA 100 XX 99
AA 100 YY 11
AA 100 ZZ 101
BB 200 XX 99
BB 200 YY 11
BB 200 ZZ 101
CC 300 XX 99
CC 300 YY 11
CC 300 ZZ 101
Note: The number of rows in the output will always be the cross product of number of
rows in each table. In our example table 1 has 3 rows and table 2 has 3 rows so the output
has 3×3 = 9 rows.
Rename (ρ)
Rename (ρ) operation can be used to rename a relation or an attribute of a relation.
Rename (ρ) Syntax:
ρ(new_relation_name, old_relation_name)
Rename (ρ) Example

Let’s say we have a table customer, we are fetching customer names and we are renaming
the resulted relation to CUST_NAMES.
Table: CUSTOMER

----------- ------------- -------------
C10100 Steve Agra
C10111 Raghu Agra
C10117 Ajeet Delhi
47
DBMS
C10118 Carl Delhi
Query:
ρ (CUST_NAMES, ∏(Customer_Name)(CUSTOMER))
Output:
CUST_NAMES
----------
Steve
Raghu
Chaitanya
Ajeet
Carl
Division Operator (÷):
Division operator A÷B can be applied if and only if:

• Attributes of B is proper subset of Attributes of A.
• The relation returned by division operator will have attributes = (All attributes of A
– All Attributes of B)
• The relation returned by division operator will return those tuples from relation A
which are associated to every B’s tuple.
NOTE: Proper Subset: A proper subset of a set A is a subset of A that is not equal to A.
In other words, if B is a proper subset of A, then all elements of B are in A but A contains
at least one element that is not in B.
Keys in DBMS
Key plays an important role in relational database; it is used for identifying unique rows
from table. It also establishes relationship among tables.
48
DBMS
Types of keys in DBMS

Primary Key:
A primary is a column or set of columns in a table that uniquely identifies tuples (rows)
in that table.
Let’s take an example to understand the concept of primary key. In the following table,
there are three attributes: Stu_ID, Stu_Name & Stu_Age. Out of these three attributes,
one attribute or a set of more than one attributes can be a primary key.
Attribute Stu_Name alone cannot be a primary key as more than one students can have
same name.
Attribute Stu_Age alone cannot be a primary key as more than one students can have
same age.
Attribute Stu_Id alone is a primary key as each student has a unique id that can identify
the student record in the table.
Note: In some cases an attribute alone cannot uniquely identify a record in a table, in that
case we try to find a set of attributes that can uniquely identify a row in table.
Table Name: STUDENT

101 Steve 23
102 John 24
103 Robert 28
104 Steve 29
105 Carl 29
49
DBMS
Points to Note regarding Primary Key

• We usually denote it by underlining the attribute name (column name).
• The value of primary key should be unique for each row of the table. The column(s)
that makes the key cannot contain duplicate values.
• The attribute(s) that is marked as primary key is not allowed to have null values.
• Primary keys are not necessarily to be a single attribute (column). It can be a set of
more than one attributes (columns). For example {Stu_Id, Stu_Name} collectively
can identify the tuple in the above table, but we do not choose it as primary key
because Stu_Id alone is enough to uniquely identifies rows in a table and we always
go for minimal set. Having that said, we should choose more than one columns as
primary key only when there is no single column that can uniquely identify the tuple
in table.
Another example of primary key – More than one attributes
Consider this table ORDER, this table keeps the daily record of the purchases made by
the customer. This table has three
attributes: Customer_ID, Product_ID & Order_Quantity.
Customer_ID alone cannot be a primary key as a single customer can place more than
one order thus more than one rows of same Customer_ID value. As we see in the
following example that customer id 1011 has placed two orders with product_ID 9023
and 9111.
Product_ID alone cannot be a primary key as more than one customers can place a order
for the same product thus more than one rows with same product id. In the following
table, customer id 1011 & 1122 placed an order for the same product (product id 9023).
Order_Quantity alone cannot be a primary key as more than one customers can place the
order for the same quantity.
50
DBMS
Since none of the attributes alone were able to become a primary key, let’s try to make a
set of attributes that plays the role of it.
{Customer_ID, Product_ID} together can identify the rows uniquely in the table so this
set is the primary key for this table.
Table Name: ORDER
Customer_ID Product_ID Order_Quantity

1011 9023 10
1122 9023 15
1099 9031 20
1177 9031 18
1011 9111 50
Note: While choosing a set of attributes for a primary key, we always choose the minimal
set that has minimum number of attributes. For example, if there are two sets that can
identify row in table, the set that has minimum number of attributes should be chosen as
primary key.
How to define primary key in RDBMS?

Let’s say we want to create the table that we have discussed above with the customer id
and product id set working as primary key. We can do that in SQL like this:
Create table ORDER

(
Customer_ID int not null,
Product_ID int not null,
Order_Quantity int not null,
Primary key (Customer_ID, Product_ID)
);
51
DBMS
Suppose we didn’t define the primary key while creating table then we can define it later
like this:
ALTER TABLE ORDER

ADD CONSTRAINT PK_Order PRIMARY KEY (Customer_ID, Product_ID);
Another way:
When we have only one attribute as primary key, like we see in the first example of
STUDENT table. We can define the key like this as well:
Create table STUDENT

(
Stu_Id int primary key,
Stu_Name varchar(255) not null,
Stu_Age int not null
)
Super key in DBMS
Definition of Super Key in DBMS: A super key is a set of one or more attributes
(columns), which can uniquely identify a row in a table. Often DBMS beginners get
confused between super key and candidate key, so we will also discuss candidate key and
its relation with super key.
How candidate key is different from super key?

Answer is simple – Candidate keys are selected from the set of super keys, the only thing
we take care while selecting candidate key is: It should not have any redundant attribute.
That’s the reason they are also termed as minimal super key.
Let’s take an example to understand this:
Table: Employee
Emp_SSN Emp_Number Emp_Name

--------- ---------- --------
123456789 226 Steve
999999321 227 Ajeet
52
DBMS
888997212 228 Chaitanya

777778888 229 Robert
Super keys: The above table has following super keys. All of the following sets of super
key are able to uniquely identify a row of the employee table.
• {Emp_SSN}
• {Emp_Number}
• {Emp_SSN, Emp_Number}
• {Emp_SSN, Emp_Name}
• {Emp_SSN, Emp_Number, Emp_Name}
• {Emp_Number, Emp_Name}
Candidate Keys: As I mentioned in the beginning, a candidate key is a minimal super

key with no redundant attributes. The following two set of super keys are chosen from the
above sets as there are no redundant attributes in these sets.
• {Emp_SSN}
• {Emp_Number}
Only these two sets are candidate keys as all other sets are having redundant attributes
that are not necessary for unique identification.
Super key vs Candidate Key

1. First you have to understand that all the candidate keys are super keys. This is because
the candidate keys are chosen out of the super keys.
2. How we choose candidate keys from the set of super keys? We look for those keys
from which we cannot remove any fields. In the above example, we have not chosen
{Emp_SSN, Emp_Name} as candidate key because {Emp_SSN} alone can identify a
unique row in the table and Emp_Name is redundant.
53
DBMS
A Primary key is selected from a set of candidate keys. This is done by database admin or
database designer. We can say that either {Emp_SSN} or {Emp_Number} can be chosen
as a primary key for the table Employee.
Candidate Key in DBMS

Definition of Candidate Key in DBMS: A super key with no redundant attribute is
known as candidate key. Candidate keys are selected from the set of super keys, the only
thing we take care while selecting candidate key is that the candidate key should not have
any redundant attributes. That’s the reason they are also termed as minimal super key.
Candidate Key Example

Lets take an example of table “Employee”. This table has three attributes: Emp_Id,
Emp_Number & Emp_Name. Here Emp_Id & Emp_Number will be having unique
values and Emp_Name can have duplicate values as more than one employees can have
same name.
Emp_Id Emp_Number Emp_Name

------ ---------- --------
E01 2264 Steve
E22 2278 Ajeet
E23 2288 Chaitanya
E45 2290 Robert
How many super keys the above table can have?

1. {Emp_Id}
2. {Emp_Number}
3. {Emp_Id, Emp_Number}
4. {Emp_Id, Emp_Name}
5. {Emp_Id, Emp_Number, Emp_Name}
6. {Emp_Number, Emp_Name}
Let’s select the candidate keys from the above set of super keys.
54
DBMS
1. {Emp_Id} – No redundant attributes.

2. {Emp_Number} – No redundant attributes.
3. {Emp_Id, Emp_Number} – Redundant attribute. Either of those attributes can be a
minimal super key as both of these columns have unique values.
4. {Emp_Id, Emp_Name} – Redundant attribute Emp_Name.
5. {Emp_Id, Emp_Number, Emp_Name} – Redundant attributes. Emp_Id or
Emp_Number alone are sufficient enough to uniquely identify a row of Employee table.
6. {Emp_Number, Emp_Name} – Redundant attribute Emp_Name.
The candidate keys we have selected are:

{Emp_Id}
{Emp_Number}
Note: A primary key is selected from the set of candidate keys. That means we can either
have Emp_Id or Emp_Number as primary key. The decision is made by DBA (Database
administrator)
Alternate key in DBMS

As we have seen in the candidate key that a table can have multiple candidate keys.
Among these candidate keys, only one key gets selected as primary key, the remaining
keys are known as alternative or secondary keys.
Alternate Key Example

Let’s take an example to understand the alternate key concept. Here we have a table
Employee, this table has three attributes: Emp_Id, Emp_Number & Emp_Name.
Table: Employee
Emp_Id Emp_Number Emp_Name

------ ---------- --------
E01 2264 Steve
55
DBMS
E22 2278 Ajeet

E23 2288 Chaitanya
E45 2290 Robert
There are two candidate keys in the above table:

{Emp_Id}
{Emp_Number}
DBA (Database administrator) can choose any of the above key as primary key. Let’s say
Emp_Id is chosen as primary key.
Since we have selected Emp_Id as primary key, the remaining key Emp_Number would
be called alternative or secondary key.
Foreign key in DBMS

Definition: Foreign keys are the columns of a table that points to the primary key of
another table. They act as a cross-reference between tables.
For example:
In the below example the Stu_Id column in Course_enrollment table is a foreign key as
it points to the primary key of the Student table.
Course_enrollment table:
Course_Id Stu_Id
C01 101
C02 102
C03 101
C05 102
C06 103
C07 102
56
DBMS
Student table:

101 Chaitanya 22
102 Arya 26
103 Bran 25
104 Jon 21
Note: Practically, the foreign key has nothing to do with the primary key tag of another
table, if it points to a unique column (not necessarily a primary key) of another table then
too, it would be a foreign key. So, a correct definition of foreign key would be: Foreign
keys are the columns of a table that points to the candidate key of another table.
Composite key Example

Let’s consider a table Sales. This table has four columns (attributes) – cust_Id, order_Id,
product_code & product_count.
Table – Sales
cust_Id order_Id product_code product_count

-------- -------- ------------ -------------
C01 O001 P007 23
C02 O123 P007 19
C02 O123 P230 82
C01 O001 P890 42
None of these columns alone can play a role of key in this table.
Column cust_Id alone cannot become a key as a same customer can place multiple
orders, thus the same customer can have multiple entires.
57
DBMS
Column order_Id alone cannot be a primary key as a same order can contain the order of
multiple products, thus same order_Id can be present multiple times.
Column product_code cannot be a primary key as more than one customers can place
order for the same product.
Column product_count alone cannot be a primary key because two orders can be placed
for the same product count.
Based on this, it is safe to assume that the key should be having more than one attributes:
Key in above table: {cust_id, product_code}
This is a composite key as it is made up of more than one attributes.
SQL Data Types

SQL data types can be broadly divided into following categories.
1. Numeric data types such as int, tinyint, bigint, float, real etc.
2. Date and Time data types such as Date, Time, Datetime etc.
3. Character and String data types such as char, varchar, text etc.
4. Unicode character string data types, for example nchar, nvarchar, ntext etc.
5. Binary data types such as binary, varbinary etc.
6. Miscellaneous data types – clob, blob, xml, cursor, table etc.
58
DBMS
Let’s look into different categories of sql data types in detail.
SQL Numeric Data Types
DATATYPE FROM TO
bit 0 1
tinyint 0 255
smallint -32,768 32,767
int -2,147,483,648 2,147,483,647
bigint -9,223,372,036,854,775,808 9,223,372,036,854,775,807
decimal -10^38 +1 10^38 -1
numeric -10^38 +1 10^38 -1
float -1.79E + 308 1.79E + 308
real -3.40E + 38 3.40E + 38
59
DBMS
SQL Date and Time Data Types

DATATYPE DESCRIPTION
DATE Stores date in the format YYYY-MM-DD
TIME Stores time in the format HH:MI:SS
DATETIME Stores date and time information in the format YYYY-MM-DD HH:MI:SS
TIMESTAMP Stores number of seconds passed since the Unix epoch (‘1970-01-01
00:00:00’ UTC)
YEAR Stores year in 2 digit or 4 digit format. Range 1901 to 2155 in 4-digit
format. Range 70 to 69, representing 1970 to 2069.
SQL Character and String Data Types

CHAR Fixed length with maximum length of 8,000 characters
VARCHAR Variable length storage with maximum length of 8,000

characters
VARCHAR(max) Variable length storage with provided max characters, not

supported in MySQL
TEXT Variable length storage with maximum size of 2GB data
Note that all the above data types are for character stream, they should not be used with
unicode data.
SQL Unicode Character and String Data Types
NCHAR Fixed length with maximum length of 4,000 characters
NVARCHAR Variable length storage with maximum length of 4,000

characters
NVARCHAR(max) Variable length storage with provided max characters
60
DBMS
NTEXT Variable length storage with maximum size of 1GB data
Note that above data types are not supported in MySQL database.
What is the difference between varchar & varchar2 in SQL?

Varchar2 stands for variable length character string2. Major difference between these two
data types is the way how they treat an empty string and NULL Value. For Varchar
empty string and Null value are two different things while varchar2 treat these two things
in the same way i.e. if you think that a column in your table contains Null value as well
as some empty string but for that column both means the same then you should use
Varchar2 or in case you think both are two different values for the same column then you
should go for varchar2.
SQL Binary Data Types
BINARY Fixed length with maximum length of 8,000 bytes
VARBINARY Variable length storage with maximum length of 8,000 bytes
VARBINARY(max) Variable length storage with provided max bytes
IMAGE Variable length storage with maximum size of 2GB binary

data
SQL Miscellaneous Data Types
CLOB Character large objects that can hold up to 2GB
BLOB For binary large objects
XML for storing xml data
JSON for storing JSON data
61
DBMS
SQL JOIN
SQL Join is used to fetch data from two or more tables, which is joined to appear as
single set of data. It is used for combining column from two or more tables by using
values common to both tables.
Types of JOIN
Following are the types of JOIN that we can use in SQL:
• Inner
• Outer
• Left
• Right
INNER Join or EQUI Join

The INNER JOIN keyword selects all rows from both the tables as long as the condition
satisfies. This keyword will create the result-set by combining all rows from both the
tables where the condition satisfies i.e. value of the common field will be same.
Example of INNER JOIN

Consider a class table,
ID NAME
1 abhi
2 adam
3 alex
4 anu
62
DBMS
And the class_info table,

ID Address
1 DELHI
2 MUMBAI
3 CHENNAI
Inner JOIN query will be,

SELECT * from class INNER JOIN class_info where class.id = class_info.id;
The result-set table will look like,
ID NAME ID Address
1 abhi 1 DELHI
2 adam 2 MUMBAI
3 alex 3 CHENNAI
Natural JOIN
Natural Join is a type of Inner join which is based on column having same name and
same data type present in both the tables to be joined.
Example of Natural JOIN

Here is the class table,
ID NAME
1 abhi
2 adam
3 alex
4 anu
ID Address
63
DBMS
1 DELHI
2 MUMBAI
3 CHENNAI
Natural join query will be,

SELECT * from class NATURAL JOIN class_info;
ID NAME Address
1 abhi DELHI
2 adam MUMBAI
3 alex CHENNAI
In the above example, both the tables being joined have ID column (same name and same
data type), hence the records for which value of ID matches in both the tables will be the
result of Natural Join of these two tables.
OUTER JOIN
Outer Join is based on both matched and unmatched data. Outer Joins subdivide further
into,
1. Left Outer Join

2. Right Outer Join
3. Full Outer Join
Left Outer Join

The left outer join returns a result-set table with the matched data from the two tables
and then the remaining rows of the left table and null from the right table's columns.
To specify a condition, we use the ON keyword with Outer Join.
64
DBMS
NOTE:
This join returns all the rows of the table on the left side of the join and matching rows
for the table on the right side of join. The rows for which there is no matching row on
right side, the result-set will contain null. LEFT JOIN is also known as LEFT OUTER
JOIN.
Example of Left Outer Join

Here is the class table,
ID NAME
1 abhi
2 adam
3 alex
4 anu
5 ashish
ID Address
1 DELHI
2 MUMBAI
3 CHENNAI
7 NOIDA
8 PANIPAT
Left Outer Join query will be,
65
DBMS
SELECT * FROM class LEFT OUTER JOIN class_info ON (class.id = class_info.id);

ID NAME ID Address
1 abhi 1 DELHI
2 adam 2 MUMBAI
3 alex 3 CHENNAI
4 anu null null
5 ashish null null
RIGHT Outer Join

The right outer join returns a result-set table with the matched data from the two tables
being joined, then the remaining rows of the right table and null for the remaining left
table's columns.
NOTE:
RIGHT JOIN is similar to LEFT JOIN. This join returns all the rows of the table on the
right side of the join and matching rows for the table on the left side of join. The rows for
which there is no matching row on left side, the result-set will contain null. RIGHT JOIN
is also known as RIGHT OUTER JOIN.
Example of Right Outer Join

Once again the class table,
66
DBMS
ID NAME
1 Abhi
2 Adam
3 Alex
4 Anu
5 Ashish
ID Address
1 DELHI
2 MUMBAI
3 CHENNAI
7 NOIDA
8 PANIPAT
Right Outer Join query will be,

SELECT * FROM class RIGHT OUTER JOIN class_info ON (class.id = class_info.id);
The resultant table will look like,
ID NAME ID Address
1 abhi 1 DELHI
2 adam 2 MUMBAI
3 alex 3 CHENNAI
Null null 7 NOIDA
Null null 8 PANIPAT
67
DBMS
Full Outer Join

The full outer join returns a result-set table with the matched data of two table then
remaining rows of both left table and then the right table.
Example of Full outer join is,

The class table,
ID NAME
1 abhi
2 adam
3 alex
4 anu
5 ashish
ID Address
1 DELHI
2 MUMBAI
3 CHENNAI
7 NOIDA
8 PANIPAT
Full Outer Join query will be like,

SELECT * FROM class FULL OUTER JOIN class_info ON (class.id = class_info.id);
68
DBMS
ID NAME ID Address
1 abhi 1 DELHI
2 adam 2 MUMBAI
3 alex 3 CHENNAI
4 anu null null
5 ashish null null
Null null 7 NOIDA
Null null 8 PANIPAT
SQL Trigger
Trigger: A trigger is a stored procedure in database which automatically invokes
whenever a special event in the database occurs. For example, a trigger can be invoked
when a row is inserted into a specified table or when certain table columns are being
updated.
Triggers are stored programs, which are automatically executed or fired when some
events occur. Triggers are, in fact, written to be executed in response to any of the
following events
➢ A database manipulation (DML) statement (DELETE, INSERT, or

UPDATE)
➢ A database definition (DDL) statement (CREATES, ALTER, or DROP).
➢ A database operation (SERVER ERROR, LOGON, LOGOFF, STARTUP,

or SHUTDOWN).
In MySQL, a trigger is a stored program invoked automatically in response to an event

such as insert, update, or delete that occurs in the associated table. For example, you
can define a trigger that is invoked automatically before a new row is inserted into a
table.
69
DBMS
The SQL standard defines two types of triggers: row-level triggers and statement-level
triggers.
• A row-level trigger is activated for each row that is inserted, updated, or

deleted. For example, if a table has 100 rows inserted, updated, or deleted, the
trigger is automatically invoked 100 times for the 100 rows affected.
• A statement-level trigger is executed once for each transaction regardless of how

many rows are inserted, updated, or deleted.
MySQL supports only row-level triggers. It doesn’t support statement-level triggers.
Syntax:
create trigger [trigger_name]

[before | after]
{insert | update | delete}
on [table_name]
[for each row]
[trigger_body]
1. create trigger [trigger_name]: Creates or replaces an existing trigger with the

trigger_name.
2. [before | after]: This specifies when the trigger will be executed.
3. {insert | update | delete}: This specifies the DML operation.
4. on [table_name]: This specifies the name of the table associated with the trigger.
5. [for each row]: This specifies a row-level trigger, i.e., the trigger will be executed
for each row being affected.
6. [trigger_body]: This provides the operation to be performed as trigger is fired
70
DBMS
Benefits of Triggers
Triggers can be written for the following purposes −
• Generating some derived column values automatically

• Enforcing referential integrity
• Event logging and storing information on table access
• Auditing
• Synchronous replication of tables

• Imposing security authorizations
• Preventing invalid transactions
Creating Triggers
The syntax for creating a trigger is:
CREATE [OR REPLACE ] TRIGGER trigger_name

{BEFORE | AFTER | INSTEAD OF}
{INSERT | UPDATE | DELETE}
[OF col_name]
ON table_name
[REFERENCING OLD AS o NEW AS n]
[FOR EACH ROW]
WHEN (condition)
DECLARE
Declaration-statements
BEGIN
Executable-statements
EXCEPTION
Exception-handling-statements
END;
71
DBMS
Where,
➢ CREATE [OR REPLACE] TRIGGER trigger_name − Creates or replaces an
existing trigger with the trigger_name.
➢ {BEFORE | AFTER | INSTEAD OF} − This specifies when the trigger will be
executed. The INSTEAD OF clause is used for creating trigger on a view.
➢ {INSERT [OR] | UPDATE [OR] | DELETE} − This specifies the DML operation.
➢ [OF col_name] − This specifies the column name that will be updated.
➢ [ON table_name] − This specifies the name of the table associated with the
trigger.
➢ [REFERENCING OLD AS o NEW AS n] − This allows you to refer new and old
values for various DML statements, such as INSERT, UPDATE, and DELETE.
➢ [FOR EACH ROW] − This specifies a row-level trigger, i.e., the trigger will be
executed for each row being affected. Otherwise the trigger will execute just once
when the SQL statement is executed, which is called a table level trigger.
➢ WHEN (condition) − This provides a condition for rows for which the trigger
would fire. This clause is valid only for row-level triggers.
NOTE:
1. OLD and NEW references are not available for table-level triggers, rather
you can use them for record-level triggers.
2. The above trigger has been written in such a way that it will fire before any
DELETE or INSERT or UPDATE operation on the table, but you can write
your trigger on a single or multiple operations, for example BEFORE
DELETE, which will fire whenever a record will be deleted using the
DELETE operation on the table.
72
DBMS
Example
Select * from customers;
+----+----------+-----+-----------+----------+
| ID | NAME | AGE | ADDRESS | SALARY |
+----+----------+-----+-----------+----------+
| 1 | Ramesh | 32 | Ahmedabad | 2000.00 |
| 2 | Khilan | 25 | Delhi | 1500.00 |
| 3 | kaushik | 23 | Kota | 2000.00 |
| 4 | Chaitali | 25 | Mumbai | 6500.00 |
| 5 | Hardik | 27 | Bhopal | 8500.00 |
| 6 | Komal | 22 | MP | 4500.00 |
+----+----------+-----+-----------+----------+
The following program creates a row-level trigger for the customers table that would fire
for INSERT or UPDATE or DELETE operations performed on the CUSTOMERS table.
This trigger will display the salary difference between the old values and new values:
CREATE OR REPLACE TRIGGER display_salary_changes

BEFORE DELETE OR INSERT OR UPDATE ON customers
FOR EACH ROW
WHEN (NEW.ID > 0)
DECLARE
sal_diff number;
BEGIN
sal_diff := :NEW.salary - :OLD.salary;
dbms_output.put_line('Old salary: ' || :OLD.salary);
dbms_output.put_line('New salary: ' || :NEW.salary);
dbms_output.put_line('Salary difference: ' || sal_diff);
END;
When the above code is executed at the SQL prompt, it produces the following result:
Trigger created.
Triggering a Trigger
Let us perform some DML operations on the CUSTOMERS table. Here is one INSERT
statement, which will create a new record in the table −
73
DBMS
INSERT INTO CUSTOMERS (ID, NAME, AGE, ADDRESS, SALARY)

VALUES (7, 'Kriti', 22, 'HP', 7500.00);
When a record is created in the CUSTOMERS table, the above create
trigger, display_salary_changes will be fired and it will display the following result −
Old salary:
New salary: 7500
Salary difference:
Because this is a new record, old salary is not available and the above result comes as
null. Let us now perform one more DML operation on the CUSTOMERS table. The
UPDATE statement will update an existing record in the table −
UPDATE customers
SET salary = salary + 500
WHERE id = 2;
When a record is updated in the CUSTOMERS table, the above create
trigger, display_salary_changes will be fired and it will display the following result −
Old salary: 1500

New salary: 2000
Salary difference: 500
Assertion
Assertions are used to specify integrity constraints which cannot be specified using
constraints like primary key, not null, unique, default, check etc.
1. Assertion is an expression or constraint that should be always true.
2. DBMS enforces the assertion on the database and the constraints specified
in assertion must not be violated.
3. DBMS always checks the assertion whenever modifications are done in
corresponding table.
Syntax:
Create assertion <assertion_name> check (condition);
DBMS tests the assertion for its validity when it is created.

74
DBMS
Ex:
The price of the textbook must not be less than the minimum price of a novel.
Create assertion price_constraint check(NOT EXISTS (select * from BOOK where

category=’textbook’ AND (price <(select MIN(price) from BOOK where
category=’Novel’))))
➢ NOT EXISTS indicates that the result of this query must be empty.
➢ Assertion is violated whenever the result of query inside NOT EXISTS clause is
not empty
NOTE
➢ Triggers - a trigger is a piece of SQL to execute either before or after an update,
inserts, or delete in a database.
The difference between assertions and checks is a little murkier; many databases don't
even support assertions
➢ Check Constraint - A check is a piece of SQL which makes sure a condition is
satisfied before action can be taken on a record.
ALTER TABLE accounts ALTER TABLE accounts

ADD CONSTRAINT CK_minimumBalance OR ADD CHECK (balance >= 100)
CHECK (balance >= 100)
Any attempt to insert a value in the balance column of less than 100 would throw an
error.
➢ Assertions - An assertion is a piece of SQL which makes sure a condition is
satisfied or it stops action being taken on a database object.
75
DBMS
Java JDBC
JDBC stands for Java Database Connectivity. JDBC is a Java API to connect and
execute the query with the database.
JDBC API is a Java API that can access any kind of tabular data, especially data stored in
a Relational Database. JDBC works with Java on a variety of platforms, such as
Windows, Mac OS, and the various versions of UNIX.
Java Database Connectivity, which is a standard Java API for database connectivity
between the Java programming language and a wide range of databases.
JDBC API uses JDBC drivers to connect with the database. There are four types of JDBC
drivers:
• JDBC-ODBC Bridge Driver,

• Native Driver,
• Network Protocol Driver, and
• Thin Driver
We can use JDBC API to access tabular data stored in any relational database. By the
help of JDBC API, we can save, update, delete and fetch data from the database. It is like
Open Database Connectivity (ODBC) provided by Microsoft.
The JDBC library includes APIs for each of the tasks mentioned below that are
commonly associated with database usage.
76
DBMS
• Making a connection to a database.

• Creating SQL or MySQL statements.
• Executing SQL or MySQL queries in the database.
• Viewing & Modifying the resulting records.
A list of popular interfaces of JDBC API is given below:
• Driver interface
• Connection interface
• Statement interface
• PreparedStatement interface
• CallableStatement interface
• ResultSet interface
• ResultSetMetaData interface
• DatabaseMetaData interface
• RowSet interface
A list of popular classes of JDBC API is given below:
• DriverManager class
• Blob class
• Clob class
• Types class
Why Should We Use JDBC?
Before JDBC, ODBC API was the database API to connect and execute the query with
the database. But, ODBC API uses ODBC driver which is written in C language (i.e.
platform dependent and unsecured). That is why Java has defined its own API (JDBC
API) that uses JDBC drivers (written in Java language).
We can use JDBC API to handle database using Java program and can perform the
following activities:
1. Connect to the database

2. Execute queries and update statements to the database
3. Retrieve the result received from the database.
77
DBMS
What is API
API (Application programming interface) is a document that contains a description of all

the features of a product or software. It represents classes and interfaces that software
programs can follow to communicate with each other. An API can be created for
applications, libraries, operating systems, etc.
JDBC Driver
JDBC Driver is a software component that enables java application to interact with the
database. There are 4 types of JDBC drivers:
1. JDBC-ODBC bridge driver
2. Native-API driver (partially java driver)
3. Network Protocol driver (fully java driver)
4. Thin driver (fully java driver)
JDBC-ODBC bridge driver
The JDBC-ODBC bridge driver uses ODBC driver to connect to the database. The
JDBC-ODBC bridge driver converts JDBC method calls into the ODBC function calls.
This is now discouraged because of thin driver.
Oracle does not support the JDBC-ODBC Bridge from Java 8. Oracle recommends that
you use JDBC drivers provided by the vendor of your database instead of the JDBC-
ODBC Bridge.
Advantages:
• Easy to use.
• Can be easily connected to any database.
Disadvantages:
• Performance degraded because JDBC method call is converted into the ODBC
function calls.
78
DBMS
• The ODBC driver needs to be installed on the client machine.
Native-API driver
The Native API driver uses the client-side libraries of the database. The driver converts
JDBC method calls into native calls of the database API. It is not written entirely in java.
Advantage:
• Performance upgraded than JDBC-ODBC bridge driver.
Disadvantage:
• The Native driver needs to be installed on the each client machine.
• The Vendor client library needs to be installed on client machine.
Network Protocol driver
The Network Protocol driver uses middleware (application server) that converts JDBC
calls directly or indirectly into the vendor-specific database protocol. It is fully written in
java.
Advantage:
• No client side library is required because of application server that can perform
many tasks like auditing, load balancing, logging etc.
Disadvantages:
• Network support is required on client machine.
• Requires database-specific coding to be done in the middle tier.
• Maintenance of Network Protocol driver becomes costly because it requires
database-specific coding to be done in the middle tier.
Thin driver
The thin driver converts JDBC calls directly into the vendor-specific database protocol.
That is why it is known as thin driver. It is fully written in Java language.
Advantage:
• Better performance than all other drivers.
• No software is required at client side or server side.
79
DBMS
Disadvantage:
• Drivers depend on the Database.
Java Database Connectivity with 5 Steps

There are 5 steps to connect any java application with the database using JDBC. These
steps are as follows:
• Register the Driver class
• Create connection
• Create statement
• Execute queries
• Close connection
Register the driver class
The forName() method of Class class is used to register the driver class. This method is
used to dynamically load the driver class.
Example to register the OracleDriver class
Here, Java program is loading oracle driver to establish database connection.
Class.forName("oracle.jdbc.driver.OracleDriver");
Create the connection object
The getConnection() method of DriverManager class is used to establish connection with

the database.
Create the Statement object
The createStatement() method of Connection interface is used to create statement. The

object of statement is responsible to execute queries with the database.
Example to create the statement object
Statement stmt=con.createStatement();
80
DBMS
Execute the query
The executeQuery() method of Statement interface is used to execute queries to the

database. This method returns the object of ResultSet that can be used to get all the
records of a table.
Example to execute query
ResultSet rs=stmt.executeQuery("select * from emp");
while(rs.next())
System.out.println(rs.getInt(1)+" "+rs.getString(2));
Close the connection object
By closing connection object statement and ResultSet will be closed automatically. The
close() method of Connection interface is used to close the connection.
Example to close connection
con.close();
Java Database Connectivity with Oracle
To connect java application with the oracle database, we need to follow 5 following
steps. In this example, we are using Oracle 10g as the database. So we need to know
following information for the oracle database:
Driver class: The driver class for the oracle database is oracle.jdbc.driver.OracleDriver.
Connection URL: The connection URL for the oracle10G database is

jdbc:oracle:thin:@localhost:1521:xe where jdbc is the API, oracle is the database, thin is
the driver, localhost is the server name on which oracle is running, we may also use IP
address, 1521 is the port number and XE is the Oracle service name. You may get all
these information from the tnsnames.ora file.
81
DBMS
Username: The default username for the oracle database is system.
Password: It is the password given by the user at the time of installing the oracle
database.
Create a Table
Before establishing connection, let's first create a table in oracle database. Following is
the SQL query to create a table.
create table emp(id number(10),name varchar2(40),age number(3));
Example to Connect Java Application with Oracle database
In this example, we are connecting to an Oracle database and getting data from emp
table. Here, system and oracle are the username and password of the Oracle database.
import java.sql.*;
class OracleCon
{
public static void main(String args[])
{
try{
//step1 load the driver class
Class.forName("oracle.jdbc.driver.OracleDriver");
//step2 create the connection object

Connection con=DriverManager.getConnection(
"jdbc:oracle:thin:@localhost:1521:xe","system","oracle");
//step3 create the statement object

Statement stmt=con.createStatement();
//step4 execute query

ResultSet rs=stmt.executeQuery("select * from emp");
while(rs.next())
System.out.println(rs.getInt(1)+" "+rs.getString(2)+" "+rs.getInt(3));
//step5 close the connection object

con.close();
}catch(Exception e){ System.out.println(e);}
82
DBMS
}
}
83
DBMS
To connect java application with the Oracle database ojdbc14.jar file is required to be
loaded.
Two ways to load the jar file:
1. paste the ojdbc14.jar file in jre/lib/ext folder

2. set classpath
84
DBMS
Stored Procedures
What is a Stored Procedure?
A stored procedure is a prepared SQL code that you can save, so the code can be reused
over and over again.
So if you have an SQL query that you write over and over again, save it as a stored
procedure, and then just call it to execute it.
You can also pass parameters to a stored procedure, so that the stored procedure can act
based on the parameter value(s) that is passed.
Stored Procedure Syntax
CREATE PROCEDURE procedure_name

AS
sql_statement
GO;
Execute a Stored Procedure
EXEC procedure_name;
"Customers" table
Customer_Id Customer_Name City Postal_code

1 Amith Shivamogga 577201
2 Akshay Bangaluru 530068
2 Ankith Mysore 570001
Stored Procedure Example
The following SQL statement creates a stored procedure named "SelectAllCustomers"

that selects all records from the "Customers" table:
Example
85
DBMS
CREATE PROCEDURE SelectAllCustomers

AS
SELECT * FROM Customers
GO;
Execute the stored procedure above as follows:
EXEC SelectAllCustomers;
Stored Procedure with One Parameter
The following SQL statement creates a stored procedure that selects Customers from a
particular City from the "Customers" table:
Example
CREATE PROCEDURE SelectAllCustomers @City nvarchar(30)
AS
SELECT * FROM Customers WHERE City = @City
GO;
EXEC SelectAllCustomers @City = "Shivamogga";
Stored Procedure with Multiple Parameters
Setting up multiple parameters is very easy. Just list each parameter and the data type
separated by a comma as shown below.
The following SQL statement creates a stored procedure that selects Customers from a
particular City with a particular Postal_code from the "Customers" table:
Example
CREATE PROCEDURE SelectAllCustomers @City nvarchar(30), @PostalCode integer

AS
SELECT * FROM Customers WHERE City = @City AND PostalCode = @PostalCode
86
DBMS
GO;
EXEC SelectAllCustomers @City = "Shivamogga", @PostalCode = 577201;
Normalization in DBMS: 1NF, 2NF, 3NF and BCNF in Database

Normalization is a process of organizing the data in database to avoid data redundancy,
insertion anomaly, update anomaly & deletion anomaly.
Anomalies in DBMS
There are three types of anomalies that occur when the database is not normalized. These
are – Insertion, update and deletion anomaly.
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 the undesirable characteristics like Insertion,
Update and Deletion Anomalies.
• Normalization divides the larger table into the smaller table and links them using
relationship.
• The normal form is used to reduce redundancy from the database table.
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.
4NF A relation will be in 4NF if it is in Boyce Codd normal
form and has no multi-valued dependency.
5NF A relation is in 5NF if it is in 4NF and not contains any
join dependency and joining should be lossless.
87
DBMS
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.
• No non-prime attribute is dependent on the proper subset of any candidate key of
table.
88
DBMS
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
Candidate Keys: {teacher_id, subject}

Non prime attribute: teacher_age
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.
The table is in 1 NF because each attribute has atomic values. However, it is not in 2NF
because non prime attribute teacher_age is dependent on teacher_id alone which is a
proper subset of candidate key. This violates the rule for 2NF as the rule says “no non-
prime attribute is dependent on the proper subset of any candidate key of the table”.
Note: If B is a proper subset of A, then all elements of B are in A but A contains at least
one element that is not in B.
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
89
DBMS
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 at least 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_NAME EMP_ZIP EMP_STATE EMP_CITY

222 Harry 201010 UP Noida
333 Stephan 02228 US Boston
444 Lan 60007 US Chicago
555 Katharine 06389 UK Norwich
666 John 462007 MP Bhopal
90
DBMS
Super key in the table above:
{EMP_ID}, {EMP_ID, EMP_NAME}, {EMP_ID, EMP_NAME, EMP_ZIP}....so on
Candidate key: {EMP_ID}
Non-prime attributes: An attribute that is not part of any candidate key is known as non-
prime attribute. In the given table, all attributes except EMP_ID are non-prime.
Here, EMP_STATE & EMP_CITY dependent on EMP_ZIP and EMP_ZIP dependent on

EMP_ID. The non-prime attributes (EMP_STATE, EMP_CITY) transitively dependent
on super key (EMP_ID). It violates the rule of third normal form.
That's why we need to move the EMP_CITY and EMP_STATE to the new
<EMPLOYEE_ZIP> table, with EMP_ZIP as a Primary key.
EMPLOYEE table:
EMP_ID EMP_NAME EMP_ZIP
222 Harry 201010
333 Stephan 02228
444 Lan 60007
555 Katharine 06389
666 John 462007
EMPLOYEE_ZIP table:
EMP_ZIP EMP_STATE EMP_CITY
201010 UP Noida
02228 US Boston
60007 US Chicago
06389 UK Norwich
462007 MP Bhopal
91
DBMS
NOTE:
3NF:
➢ The entity should be considered already in 2NF, and no column entry should be
dependent on any other entry (value) other than the key for the table.
➢ If such an entity exists, move it outside into a new table.
➢ 3NF is achieved considered as the database is normalized.
92

DBMS Notes (New)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DBMS Notes (New)

Uploaded by

Copyright:

Available Formats

DBMS

Database Management System

Drawbacks of File system

Advantage of DBMS over file system

• No redundant data: Redundancy removed by data normalization. No data

What is the need of DBMS?

• DBMS implementation cost is high compared to the file system

Purpose of Database Systems

Database Applications – DBMS

Applications where we use Database Management Systems are:

• Telecom: There is a database to keeps track of the information regarding calls

Types of DBMS Architecture

1. Single tier architecture

1. Single tier architecture

2. Two tier architecture

3. Three tier architecture

Two tier architecture

DBMS Three Level Architecture Diagram

This architecture has three levels:

View of Data in DBMS

Entity Relationship Diagram – ER Diagram in DBMS

What is an Entity Relationship Diagram (ER Diagram)?

Rectangle: Represents Entity sets.

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

An entity is an object or component of data. An entity is represented as rectangle in an

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

An attribute that can hold multiple values is known as multivalued attribute. It is

E-R diagram with multivalued and derived attributes:

1. One to One Relationship

2. One to Many Relationship

3. Many to One Relationship

4. Many to Many Relationship

Total Participation of an Entity set

ACID properties in DBMS

Data Abstraction in DBMS

We have three levels of abstraction

Data models in DBMS

Relational model in DBMS

Stu_Id Stu_Name Stu_Age

Stu_Id Course_Id Course_Name

111 C01 Science

The ER diagram before generalization looks like this:

The ER diagram after generalization:

How to specify the NULL constraint while creating table

CREATE TABLE STUDENTS (

Specify the NULL constraint for already existing table

ALTER TABLE STUDENTS

UNIQUE Constraint enforces a column or set of columns to have unique values. If a

CREATE TABLE STUDENTS (

UNIQUE Constraint in SQL

CREATE TABLE <table_name>

CREATE TABLE STUDENTS (

Set UNIQUE Constraint on a already created table

ALTER TABLE <table_name>

ALTER TABLE STUDENTS

For multiple columns and with constraint naming:

ALTER TABLE <table_name>

ALTER TABLE STUDENTS

How to drop a UNIQUE Constraint

ALTER TABLE <table_name>

ALTER TABLE STUDENTS

CREATE TABLE STUDENT (

ALTER TABLE <table_name>

ALTER TABLE STUDENTS