What is RDBMS (Relational Database Management

System)
RDBMS stands for Relational Database Management System.

All modern database management systems like SQL, MS SQL Server, IBM DB2, ORACLE, My-SQL, and
Microsoft Access are based on RDBMS.

It is called Relational Database Management System (RDBMS) because it is based on the relational model
introduced by E.F. Codd.

How it works
Data is represented in terms of tuples (rows) in RDBMS.

A relational database is the most commonly used database. It contains several tables, and each table has its
primary key.

Due to a collection of an organized set of tables, data can be accessed easily in RDBMS.

Brief History of RDBMS

From 1970 to 1972, E.F. Codd published a paper to propose using a relational database model.

RDBMS is originally based on E.F. Codd's relational model invention.

Following are the various terminologies of RDBMS:

What is table/Relation?
Everything in a relational database is stored in the form of relations. The RDBMS database uses tables to
store data. A table is a collection of related data entries and contains rows and columns to store data. Each
table represents some real-world objects such as person, place, or event about which information is
collected. The organized collection of data into a relational table is known as the logical view of the
database.

Properties of a Relation:

o Each relation has a unique name by which it is identified in the database.

o Relation does not contain duplicate tuples.
o The tuples of a relation have no specific order.
o All attributes in a relation are atomic, i.e., each cell of a relation contains exactly one value.

A table is the simplest example of data stored in RDBMS.

Let's see the example of the student table.

ID Name AGE COURSE

1 Ajeet 24 B.Tech

2 aryan 20 C.A

3 Mahesh 21 BCA

4 Ratan 22 MCA
5 Vimal 26 BSC

What is a row or record?

A row of a table is also called a record or tuple. It contains the specific information of each entry in the
table. It is a horizontal entity in the table. For example, The above table contains 5 records.

Properties of a row:

o No two tuples are identical to each other in all their entries.

o All tuples of the relation have the same format and the same number of entries.
o The order of the tuple is irrelevant. They are identified by their content, not by their position.

Let's see one record/row in the table.

ID Name AGE COURSE

1 Ajeet 24 B.Tech

What is a column/attribute?
A column is a vertical entity in the table which contains all information associated with a specific field in a
table. For example, "name" is a column in the above table which contains all information about a student's
name.

Properties of an Attribute:

o Every attribute of a relation must have a name.

o Null values are permitted for the attributes.
o Default values can be specified for an attribute automatically inserted if no other value is specified
for an attribute.
o Attributes that uniquely identify each tuple of a relation are the primary key.

Name

Ajeet
Aryan

Mahesh

Ratan

Vimal

What is data item/Cells?

The smallest unit of data in the table is the individual data item. It is stored at the intersection of tuples and
attributes.

Properties of data items:

o Data items are atomic.

o The data items for an attribute should be drawn from the same domain.

In the below example, the data item in the student table consists of Ajeet, 24 and Btech, etc.

ID Name AGE COURSE

1 Ajeet 24 B.Tech

Degree:
The total number of attributes that comprise a relation is known as the degree of the table.

For example, the student table has 4 attributes, and its degree is 4.

ID Name AGE COURSE

1 Ajeet 24 B.Tech

2 aryan 20 C.A

3 Mahesh 21 BCA

4 Ratan 22 MCA

5 Vimal 26 BSC
 Cardinality:
In the context of a relational database, cardinality refers to the number of instances of one entity (table)
that can be related to the number of instances in another entity through a relationship. Cardinality is often
expressed as one-to-one (1:1), one-to-many (1:N), or many-to-many (N:M).

Let's consider an example with two entities: Authors and Books.

Example: Authors and Books

Entities:

1. Authors:
 Attributes: AuthorID (Primary Key), AuthorName, Email
2. Books:
 Attributes: BookID (Primary Key), Title, AuthorID (Foreign Key), PublicationYear

Relationship:

 An author can write many books, but a book is typically written by one author. This is a one-to-many
relationship.

Cardinality:

 Author → Books: One author can be related to many books (1:N).

 Books → Author: One book is related to one author (N:1).

Representation in Tables:
 Explanation:

 Jane Doe (AuthorID: 1) has written two books ("The Book of Life" and "Data Science Guide").
 John Smith (AuthorID: 2) has written one book ("Programming 101").

In this example, the cardinality of the relationship between Authors and Books is one-to-many. One author
can be associated with multiple books, but each book is associated with only one author. This is a common
scenario in a database where an author writes multiple books, but each book is attributed to a single
author.

Domain:
The domain refers to the possible values each attribute can contain. It can be specified using standard data
types such as integers, floating numbers, etc. For example, An attribute entitled Marital_Status may be
limited to married or unmarried values.

NULL Values
 The NULL value of the table specifies that the field has been left blank during record creation. It is different
from the value filled with zero or a field that contains space.

Data Integrity
Data integrity is a fundamental aspect of database management, ensuring that data is accurate, consistent, and
reliable throughout its lifecycle.

There are the following categories of data integrity exist with each RDBMS:

Entity integrity: It specifies that there should be no duplicate rows in a table.

In this table:

 StudentID is the primary key, and it uniquely identifies each student.

 There are no NULL values in the StudentID column.

This adherence to entity integrity ensures the uniqueness of each student in the Students table, and it
prevents any student from having a NULL value in the primary key column. In summary, entity integrity
ensures that each row in a table can be uniquely identified, and it helps maintain consistency and accuracy in the
database. Primary keys play a crucial role in enforcing entity integrity in relational databases.

Domain integrity: It enforces valid entries for a given column by restricting the type, the format, or the
range of values.
 Now, let's focus on the Salary column and establish domain integrity for it.

Domain Integrity for Salary:

 Data Type: The Salary column should be of a numeric data type (e.g., INTEGER, DECIMAL).
 Range: Salaries should be within a reasonable range. For example, they should not be negative.
 Format: The format of salary values should follow a consistent pattern, such as being represented in whole
numbers or with a specific number of decimal places.

If domain integrity is enforced, the Employees table should not contain values that violate these rules. Let's
consider a scenario where domain integrity is not maintained:

Domain integrity in a relational database ensures that data values within a specific column or attribute
adhere to a defined set of permissible values, including data types, ranges, and formats. Let's consider an
example to illustrate domain integrity:
 Referential integrity specifies that rows cannot be deleted, which are used by other records.

Referential integrity in a relational database ensures the consistency between related tables. It typically
involves the use of foreign keys to link rows in one table to rows in another. Let's consider an example to
illustrate referential integrity:

 The AuthorID in the Books table is a foreign key that references the primary key AuthorID in the Authors
table.
 This relationship ensures that every AuthorID in the Books table corresponds to a valid AuthorID in the
Authors table.

Referential Integrity Maintained:

If referential integrity is maintained, all values in the AuthorID column of the Books table must exist in the
AuthorID column of the Authors table. Here's an example of maintaining referential integrity:

Violation of Referencial integerity

User-defined integrity: It enforces some specific business rules defined by users. These rules are different
from the entity, domain, or referential integrity.
Difference between File System and DBMS
File System Approach
File based systems were an early attempt to computerize the manual system. It is also called a traditional
based approach in which a decentralized approach was taken where each department stored and
controlled its own data with the help of a data processing specialist. The main role of a data processing
specialist was to create the necessary computer file structures, and also manage the data within structures
and design some application programs that create reports based on file data.

In the above figure:

Consider an example of a student's file system. The student file will contain information regarding the
student (i.e. roll no, student name, course etc.). Similarly, we have a subject file that contains information
about the subject and the result file which contains the information regarding the result.
Some fields are duplicated in more than one file, which leads to data redundancy. So to overcome this
problem, we need to create a centralized system, i.e. DBMS approach.

Backward Skip 10sPlay VideoForward Skip 10s

DBMS:
A database approach is a well-organized collection of data that are related in a meaningful way which can
be accessed by different users but stored only once in a system. The various operations performed by the
DBMS system are: Insertion, deletion, selection, sorting etc.

In the above figure,

In the above figure, duplication of data is reduced due to centralization of data.

There are the following differences between DBMS and File systems:

Basis DBMS Approach File System Approach

Meaning DBMS is a collection of data. In DBMS, the The file system is a collection of data. In
user is not required to write the this system, the user has to write the
procedures. procedures for managing the database.

Sharing of data Due to the centralized approach, data Data is distributed in many files, and it
 sharing is easy. may be of different formats, so it isn't
easy to share data.

Data Abstraction DBMS gives an abstract view of data that The file system provides the detail of the
hides the details. data representation and storage of data.

Security and DBMS provides a good protection It isn't easy to protect a file under the file
Protection mechanism. system.

Recovery DBMS provides a crash recovery The file system doesn't have a crash
Mechanism mechanism, i.e., DBMS protects the user mechanism, i.e., if the system crashes
from system failure. while entering some data, then the
content of the file will be lost.

Manipulation DBMS contains a wide variety of The file system can't efficiently store and
Techniques sophisticated techniques to store and retrieve the data.
retrieve the data.

Concurrency DBMS takes care of Concurrent access of In the File system, concurrent access has
Problems data using some form of locking. many problems like redirecting the file
while deleting some information or
updating some information.

Where to use Database approach used in large systems File system approach used in large
which interrelate many files. systems which interrelate many files.

Cost The database system is expensive to The file system approach is cheaper to
design. design.

Data Redundancy Due to the centralization of the database,
and Inconsistency the problems of data redundancy and
inconsistency are controlled.
In this, the files and application
programs are created by different
programmers so that there exists a lot of
duplication of data which may lead to
inconsistency.

Structure The database structure is complex to The file system approach has a simple
design. structure.

Data In this system, Data Independence exists, In the File system approach, there exists
Independence and it can be of two types. no Data Independence.
o Logical Data Independence
o Physical Data Independence
Integrity Integrity Constraints are easy to apply. Integrity Constraints are difficult to
Constraints implement in file system.

Data Models In the database approach, 3 types of data In the file system approach, there is no
models exist: concept of data models exists.
o Hierarchal data models
o Network data models
o Relational data models

Flexibility Changes are often a necessity to the The flexibility of the system is less as
content of the data stored in any system, compared to the DBMS approach.
and these changes are more easily with a
database approach.

Examples Oracle, SQL Server, Sybase etc. Cobol, C++ etc.

DBMS Architecture

A simplified database system environment.

The Information Technology (IT) department within a company designs and maintains an information
 system consisting of various computers, storage systems, application software, and databases. Design
of a new application for an existing database or design of a brand new database starts off with a
phase called requirements specification and analysis. These requirements are documented in detail
and transformed into a conceptual design that can be represented and manipulated using some
computerized tools so that it can be easily maintained, modified, and transformed into a database
implementation. The design is then translated to a logical design that can be expressed in a data
model implemented in a commercial DBMS. The final stage is physical design, during which further
specifications are provided for storing and accessing the database. The database design is
implemented, populated with actual data, and continuously maintained to reflect the state of the mini
world.

Data Models
Data Model is the modeling of the data description, data semantics, and consistency constraints of the
data. It provides the conceptual tools for describing the design of a database at each level of data
abstraction. Therefore, there are following four data models used for understanding the structure of the
database:

1) Relational Data Model: This type of model designs the data in the form of rows and columns within
a table. Thus, a relational model uses tables for representing data and in-between relationships.
Tables are also called relations. This model was initially described by Edgar F. Codd, in 1969. The
relational data model is the widely used model which is primarily used by commercial data
processing applications.
2) Entity-Relationship Data Model: An ER model is the logical representation of data as objects and
relationships among them. These objects are known as entities, and relationship is an association
among these entities. This model was designed by Peter Chen and published in 1976 papers. It was
widely used in database designing. A set of attributes describe the entities. For example,
student_name, student_id describes the 'student' entity. A set of the same type of entities is known
as an 'Entity set', and the set of the same type of relationships is known as 'relationship set'.
3) 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.

4) Semistructured Data Model: This type of data model is different from the other three data models
(explained above). The semistructured data model allows the data specifications at places where the
 individual data items of the same type may have different attributes sets. The Extensible Markup
Language, also known as XML, is widely used for representing the semistructured data. Although
XML was initially designed for including the markup information to the text document, it gains
importance because of its application in the exchange of data.

DBMS Architecture
o The DBMS design depends upon its architecture. The basic client/server architecture is used to deal
with a large number of PCs, web servers, database servers and other components that are connected
with networks.
o The client/server architecture consists of many PCs and a workstation which are connected via the
network.
o DBMS architecture depends upon how users are connected to the database to get their request
done.

Types of DBMS Architecture

 Database architecture can be seen as a single tier or multi-tier. But logically, database architecture is of two
types like: 2-tier architecture and 3-tier architecture.

1-Tier Architecture

o In this architecture, the database is directly available to the user. It means the user can directly sit on
the DBMS and uses it.
o Any changes done here will directly be done on the database itself. It doesn't provide a handy tool
for end users.
o The 1-Tier architecture is used for development of the local application, where programmers can
directly communicate with the database for the quick response.

Here's a simple example of a one-tier architecture in a DBMS:

Scenario: Personal Contact Management System

Let's consider a basic personal contact management system where users can store and retrieve contact
information.

1. Components:
 User Interface: A simple desktop application that allows users to input, view, and manage their
contact information. The user interface is tightly integrated with the database.
 Database Engine: A local database engine running on the same machine as the user interface. It
could be a lightweight embedded database like SQLite.
2. Architecture:
 The entire application, including both the user interface and the database engine, runs on a single
computer (e.g., a personal computer).
 Users interact with the application through the graphical user interface, which directly communicates
with the embedded database engine.
3. Characteristics:
 Simplicity: This architecture is straightforward and easy to implement. There is no need for a
separate server or complex network configurations.
 Limited Scalability: As the entire application runs on a single machine, it may face limitations in
terms of scalability. It's suitable for small-scale, personal use rather than large-scale enterprise
applications.
 Easy Deployment: Since everything is contained on one machine, deployment is relatively simple.
Users can install the application on their computer without dealing with server setups.
2-Tier Architecture

o The 2-Tier architecture is same as basic client-server. In the two-tier architecture, applications on the
client end can directly communicate with the database at the server side. For this interaction, API's
like: ODBC, JDBC are used.
o The user interfaces and application programs are run on the client-side.
o The server side is responsible to provide the functionalities like: query processing and transaction
management.
o To communicate with the DBMS, client-side application establishes a connection with the server
side.

Fig: 2-tier Architecture

Let's consider a simple 2-tier architecture example for a basic online book inventory system:
1. Components:
 Client (Frontend): A desktop application or web browser that allows users to interact with the
system. It handles the presentation logic and user input.
 Server (Backend): A server-side application that manages the database, processes business logic,
and responds to client requests.
2. Architecture:
 The client communicates with the server to perform operations such as adding a new book,
retrieving book information, or updating book details.
 The server interacts with the database to store and retrieve book data.
3. Characteristics:
 Separation of Concerns: The client and server components handle different aspects of the
application, allowing for better organization and maintenance.
 Scalability: The server can be scaled independently of the client. For example, if the database load
increases, the server can be scaled up or distributed without affecting the client.
 Concurrency: Multiple clients can simultaneously interact with the server, providing a more
responsive and efficient system.
 Centralized Database: The database is typically hosted on a centralized server, allowing for better
data management and security.

3-Tier Architecture

o The 3-Tier architecture contains another layer between the client and server. In this architecture,
client can't directly communicate with the server.
o The application on the client-end interacts with an application server which further communicates
with the database system.
o End user has no idea about the existence of the database beyond the application server. The
database also has no idea about any other user beyond the application.
o The 3-Tier architecture is used in case of large web application.

Let's consider a real-world scenario for a 3-tier architecture: an online banking system.

1. Presentation Layer (Client):

 Components: A web-based interface accessible through a browser or a mobile application.
  Responsibilities: Provides a user-friendly interface for customers to view account balances, transfer
funds, pay bills, and perform other banking transactions.
Application Layer (Server):
 Components: A server-side application built with a framework like Spring Boot (Java) or Django
(Python).
 Responsibilities: Manages business logic, authentication, and communicates with the data layer for
retrieving and updating customer account information.
Data Layer (Database):
 Components: A relational database such as MySQL or PostgreSQL to store customer information,
account details, transaction history, etc.
 Responsibilities: Manages data storage, retrieval, and ensures the integrity and security of customer
data.
In this scenario, the presentation layer (client) allows users to interact with their accounts through a web interface.
The application layer (server) handles business logic such as retrieving account details and initiating fund transfers.
The data layer (database) stores customer information, account details, and transaction history. This 3-tier
architecture provides a modular and scalable structure for an online banking system, allowing for easier maintenance
and future expansions.

Fig: 3-tier Architecture

Three schema Architecture
o The three schema architecture is also called ANSI/SPARC architecture or three-level architecture.
o This framework is used to describe the structure of a specific database system.
o The three schema architecture is also used to separate the user applications and physical database.
o The three schema architecture contains three-levels. It breaks the database down into three different
categories.

The three-schema architecture is as follows:

In the above diagram:

o It shows the DBMS architecture.

 o Mapping is used to transform the request and response between various database levels of
architecture.
o Mapping is not good for small DBMS because it takes more time.
o In External / Conceptual mapping, it is necessary to transform the request from external level to
conceptual schema.
o In Conceptual / Internal mapping, DBMS transform the request from the conceptual to internal level.

Objectives of Three schema Architecture

The main objective of three level architecture is to enable multiple users to access the same data with a personalized
view while storing the underlying data only once. Thus it separates the user's view from the physical structure of the
database. This separation is desirable for the following reasons:

o Different users need different views of the same data.

o The approach in which a particular user needs to see the data may change over time.
o The users of the database should not worry about the physical implementation and internal
workings of the database such as data compression and encryption techniques, hashing,
optimization of the internal structures etc.
o All users should be able to access the same data according to their requirements.
o DBA should be able to change the conceptual structure of the database without affecting the user's
o Internal structure of the database should be unaffected by changes to physical aspects of the
storage.

1. Internal Level

o The internal level has an internal schema which describes the physical storage structure of the
database.
o The internal schema is also known as a physical schema.
 o It uses the physical data model. It is used to define that how the data will be stored in a block.
o The physical level is used to describe complex low-level data structures in detail.

The internal level is generally is concerned with the following activities:

o Storage space allocations.

For Example: B-Trees, Hashing etc.
o Access paths.
For Example: Specification of primary and secondary keys, indexes, pointers and sequencing.
o Data compression and encryption techniques.
o Optimization of internal structures.
o Representation of stored fields.

2. Conceptual Level

o The conceptual schema describes the design of a database at the conceptual level. Conceptual level
is also known as logical level.
o The conceptual schema describes the structure of the whole database.
o The conceptual level describes what data are to be stored in the database and also describes what
relationship exists among those data.
o In the conceptual level, internal details such as an implementation of the data structure are hidden.
o Programmers and database administrators work at this level.

3. External Level
 o At the external level, a database contains several schemas that sometimes called as subschema. The
subschema is used to describe the different view of the database.
o An external schema is also known as view schema.
o Each view schema describes the database part that a particular user group is interested and hides
the remaining database from that user group.
o The view schema describes the end user interaction with database systems.

Mapping between Views

The three levels of DBMS architecture don't exist independently of each other. There must be correspondence
between the three levels i.e. how they actually correspond with each other. DBMS is responsible for correspondence
between the three types of schema. This correspondence is called Mapping.

There are basically two types of mapping in the database architecture:

o Conceptual/ Internal Mapping

o External / Conceptual Mapping

Conceptual/ Internal Mapping

The Conceptual/ Internal Mapping lies between the conceptual level and the internal level. Its role is to define the
correspondence between the records and fields of the conceptual level and files and data structures of the internal
level.

External/ Conceptual Mapping

The external/Conceptual Mapping lies between the external level and the Conceptual level. Its role is to
define the correspondence between a particular external and the conceptual view.
providedfor storing and accessing the database. The database design is implemented, populated
with actual data, andcontinuously maintained to reflect the state of the miniworld.