Unit – 1

Unit – 1

Introduction to Database Management System

Data: The Collection of Organized Information is called the Data.
Database: The Organized Collection of Data, which contains relation information.
Database Management System: The Collection of interrelated Data and a collection of
Programs to access that Data.
Goal of DBMS: The goal of DBMS is to provide a way to store and retrieve information in a
convenient and efficient manner.
Properties of DBMS:
1. A Database represents some aspect of the real world. Changes to the real world
reflected in the database.
2. A Database is a logically coherent collection of data with some inherent meaning. A
random assortment of data cannot correctly be referred to as a database.
3. A Database is designed built and populated with data for a specific purpose. It has an
intended group of users and preconceived applications in which these users are
interested.
Need of DBMS:
1. Before the advent of DBMS, organizations typically stored information using a “File
Processing Systems”. Example of such systems are File Handling in High Level
Languages like C, Basic and COBOL etc., These systems have Major disadvantages
to perform the Data Manipulation. So to overcome those drawbacks now we are using
the DBMS.
2. Database systems are designed to manage large bodies of information. Management
of data involves both defining structures for storage of information and providing
mechanisms for the manipulation of information. In addition to that the database
system must ensure the safety of the information stored, despite system crashes or
attempts at unauthorized access. If data are to be shared among several users, the
system must avoid possible anomalous results.
3. The information is so important in most organizations. Computer scientists have
developed a large body of concepts and techniques for managing data.

DBMS Material Page No. 1

 Unit – 1
1.1 Database System Applications
The Databases are used in many areas and many applications. Here are some of the
Database Applications.

1. Banking: For customer information, accounts, and loans, and banking transactions.
2. Airlines: For reservations and schedule information. Airlines were among the first to
use databases in a geographically distributed manner—terminals situated around the
world accessed the central database system through phone lines and other data
networks.
3. Universities: For student information, course registrations, and grades.
4. Credit card transactions: For purchases on credit cards and generation of monthly
statements.
5. Telecommunication: For keeping records of calls made, generating monthly bills,
maintaining balances on prepaid calling cards, and storing information about the
communication networks.
6. Finance: For storing information about holdings, sales, and purchases of financial
instruments such as stocks and bonds.
7. Sales: For customer, product, and purchase information.
8. Manufacturing: For management of supply chain and for tracking production of
items in factories, inventories of items in warehouses/stores, and orders for items.
9. Human resources: For information about employees, salaries, payroll taxes and
benefits, and for generation of paychecks.
10. Railway Reservation Systems: For reservations and schedule information.
11. Web: For access the Back accounts and to get the balance amount.
12. E –Commerce: For Buying a book or music CD and browse for things like watches,
mobiles from the Internet.

DBMS Material Page No. 2

 Unit – 1
1.2 Database System Vs File System
Before the Database Management System come into existence organizations used to
store the data in Files. Drawbacks using the File System to store the data are.
1. Data redundancy and inconsistency: Multiple file formats, duplication of
information in different files Difficulty in accessing data. Unnecessary repetition of
data various copies of data may no longer agree.
2. Difficulty in Accessing Data: Need to write a new program to carry out each new
task and the data retrieval is not convenient and efficient.
3. Data Isolation: Different files and formats and difficulty in accessing data.
4. Integrity Problems: Validation entries – Difficulty in writing application programs
to enforce Integrity. Integrity constraints (e.g. account balance > 0) become part of
program code. Hard to add new constraints or change existing ones
5. Atomicity Problems: Failures may leave database in an inconsistent state with partial
updates carried out. E.g. transfer of funds from one account to another should either
complete or not happen at all. And problems of data restored during system failure.
6. Concurrent access Anomalies: Data accessed by multiple users. Concurrent
accessed needed for performance. Uncontrolled concurrent accesses can lead to
inconsistencies. E.g. two people reading a balance and updating it at the same time.
7. Security Problems: Not every user of the database system should be able to access
all the data.
Example:
Consider part of a savings-bank enterprise that keeps information about all customers
and savings accounts. One way to keep the information on a computer is to store it in
operating system files. To allow users to manipulate the information, the system has a
number of application programs that manipulate the files, including
• A program to debit or credit an account
• A program to add a new account
• A program to find the balance of an account
• A program to generate monthly statements
System programmers wrote these application programs to meet the needs of the bank.
New application programs are added to the system as the need arises. For example,
suppose that the savings bank decides to offer checking accounts. As a result, the bank
creates new permanent files that contain information about all the checking accounts
maintained in the bank, and it may have to write new application programs to deal with

DBMS Material Page No. 3

 Unit – 1
situations that do not arise in savings accounts, such as overdrafts. Thus, as time goes by, the
system acquires more files and more application programs.
The system stores permanent records in various files, and it needs different
application programs to extract records from, and add records to, the appropriate files. Before
database management systems (DBMS) came along, organizations usually stored information
in such systems.
Storing Organizational information in a file-processing system has a number of major
disadvantages:
1. Data redundancy and inconsistency: The address and telephone number of a
particular customer may appear in a file that consists of savings-account records
and in a file that consists of checking-account records. This redundancy leads to
higher storage and access cost. In addition, it may lead to data inconsistency; that
is, the various copies of the same data may no longer agree. For example, a
changed customer address may be reflected in savings-account records but not
elsewhere in the system.
2. Difficulty in accessing data: Suppose that one of the bank officers needs to find
out the names of all customers who live within a particular postal-code area. The
officer asks the data-processing department to generate such a list. Because there
is no application program to generate that. The bank officer has now two choices:
either obtain the list of all customers and extract the needed information manually
or ask a system programmer to write the necessary application program. Both
alternatives are obviously unsatisfactory.
3. 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.
4. Integrity problems: The balance of a bank account may never fall below a
prescribed amount (say, $25). Developers enforce these constraints in the system
by adding appropriate code in the various application programs. However, when
new constraints are added, it is difficult to change the programs to enforce them.
The problem is compounded when constraints involve several data items from
different files.
5. Atomicity problems: A computer system, like any other mechanical or electrical
device, is subject to failure. In many applications, it is crucial that, if a failure
occurs, the data be restored to the consistent state that existed prior to the failure.
Consider a program to transfer $50 from account A to account B. If a system

DBMS Material Page No. 4

 Unit – 1
failure occurs during the execution of the program, it is possible that the $50 was
removed from account A but was not credited to account B, resulting in an
inconsistent database state. Clearly, it is essential to database consistency that
either both the credit and debit occur, or that neither occur. That is, the funds
transfer must be atomic—it must happen in its entirety or not at all. It is difficult
to ensure atomicity in a conventional file-processing system.
6. Concurrent-access anomalies: For the sake of overall performance of the system
and faster response, many systems allow multiple users to update the data
simultaneously. In such an environment, interaction of concurrent updates may
result in inconsistent data. Consider bank account A, containing $500. If two
customers withdraw funds (say $50 and $100 respectively) from account A at
about the same time, the result of the concurrent executions may leave the account
in an incorrect (or inconsistent) state. Suppose that the programs executing on
behalf of each withdrawal read the old balance, reduce that value by the amount
being withdrawn, and write the result back. If the two programs run concurrently,
they may both read the value $500, and write back $450 and $400, respectively.
Depending on which one writes the value last, the account may contain $450 or
$400, rather than the correct value of $350. To guard against this possibility, the
system must maintain some form of supervision. But supervision is difficult to
provide because data may be accessed by many different application programs
that have not been coordinated previously.
7. Security problems: Not every user of the database system should be able to
access all the data. For example, in a banking system, payroll personnel need to
see only that part of the database that has information about the various bank
employees. They do not need access to information about customer accounts. But,
since application programs are added to the system in an ad hoc manner, enforcing
such security constraints is difficult. These difficulties, among others, prompted
the development of database systems. In what follows, we shall see the concepts
and algorithms that enable database systems to solve the problems with file-
processing systems. In most of this book, we use a bank enterprise as a running
example of a typical data-processing application found in a corporation.

DBMS Material Page No. 5

 Unit – 1
1.3 View of Data
A database system is a collection of interrelated files and a set of programs that allow
users to access and modify these files. A user will not always require the complete data the
responsibility of the database system is to provide only the data that is required to the user.
1.3.1 Data Abstraction
Hiding certain details of how the data are stored and maintained. A major purpose of database
system is to provide users with an “Abstract View” of the data. In DBMS there are 3 levels of
data abstraction. The goal of the abstraction in the DBMS is to separate the users request and
the physical storage of data in the database.
Levels of Abstraction
Physical Level: The lowest Level of Abstraction describes “How” the data are actually
stored.
Logical Level: This data Abstraction describes “What” data are to be stored in the database
and what relationships exist among those data.
View Level: It is the highest level of data Abstracts that describes only part of entire
database. Different users require different types of data elements from each database. For one
physical and logical levels of the database there may be more than one view level.
The system may provide many views for the some database.

The 3 Levels of
Data Abstraction

1.3.2 Instances & Schemas

Instances: Database change over time as information is inserted and deleted. The collection
of information stored in the database at a particular movement is called an Instance or
Database State.
Schemas: The overall design of the database is called the “Schema” or “Meta Data”. A
database schema corresponds to the programming language type definition. A Variable of a
given type has a particular value at given instant. Thus the value of a variable in
programming language corresponds to an “Instance” of a database Schema.

DBMS Material Page No. 6

 Unit – 1
The three Schema Architecture: The goal of this architecture is to separate the user
applications and the physical database.
Internal Level: This level has an internal Schema, which describes the Physical storage
structure of the database. It describes the complete details of data storage and access methods
for the database.
Conceptual Level: This level has a conceptual schema, which describes the structure of the
whole database for a community of users.
External (or) View Level: This level includes a number of external schemas or user views.
Each schema describes the part of the data that a particular user group is interested in and
hides the rest of database from other user groups.

External View 1 External View 2 ….. External View n

Conceptual Schema

Internal Schema

Stored Data

Three Schema Architecture

Data Independence:
A very important advantage of using DBMS is that it offers Data Independence. The capacity
to change the schema at one level without having change the other.
Logical Data Independence: The capacity to change the conceptual schema. The database
can be expanded (adding records) or reduced (deleting records).
Physical Data Independence: The capacity to change the physical or internal Schema.
Changes to the internal schema may be needed because some physical files had to be
recognized.
Ex: Creating additional access structures to improve the performance (Indexing).

DBMS Material Page No. 7

 Unit – 1
1.4 Data Models
Underlying the structure of a database is the data model. Data Model means to model
the data. That is to give a shape to the data or to give figure to the data. A data model makes
it easier to understand the meaning of the data by its figure.
A collection of high – level data description that hide many low – level storage
details. A data model can also be defined as a collection of conceptual tools for describing
data, data relationships, data semantics and consistency constraints. So the DBMS allows a
user to define the stored data in terms of data model.
1.4.1 E R Model
The entity-relationship (E-R) data model is based on a perception of a real world that
consists of a collection of basic objects, called entities, and of relationships among these
objects.
Entity: A real world object
E.g. customers, accounts, bank branch
Relationship: An association between entities
E.g. Pursues, works-for, managers
Attribute: Property of the Entity.
E.g. empno, ename, sal
Widely used for database design: Database design in E-R model usually converted to design
in the relational model, which is used for storage, and processing.
The overall logical structure (schema) of a database can be expressed graphically by
an E-R diagram, which is built up from the following components:
• Rectangles, which represent entity sets
• Ellipses, which represent attributes
• Diamonds, which represent relationships among entity sets
• Lines, which link attributes to entity sets and entity sets to relationships
Each component is labeled with the entity or relationship that it represents.

Example:

DBMS Material Page No. 8

 Unit – 1
1.4.2 Relational Model
(RDBMS - relational database management system) A database based on the
relational model developed by E.F. Codd. A relational database allows the definition of data
structures, storage and retrieval operations and integrity constraints. In such a database the
data and relations between them are organized in tables. A table is a collection of records and
each record in a table contains the same fields.
Properties of Relational Tables:
• Values Are Atomic
• Each Row is Unique
• Column Values Are of the Same Kind
• The Sequence of Columns is Insignificant
• The Sequence of Rows is Insignificant
• Each Column Has a Unique Name

Certain fields may be designated as keys, which mean that searches for specific values
of that field will use indexing to speed them up. Where fields in two different tables take
values from the same set, a join operation can be performed to select related records in the
two tables by matching values in those fields. Often, but not always, the fields will have the
same name in both tables. For example, an "orders" table might contain (customer-ID,
product-code) pairs and a "products" table might contain (product-code, price) pairs so to
calculate a given customer's bill you would sum the prices of all products ordered by that
customer by joining on the product-code fields of the two tables. This can be extended to
joining multiple tables on multiple fields. Because these relationships are only specified at
retrieval time, relational databases are classed as dynamic database management system. The
RELATIONAL database model is based on the Relational Algebra.

Example:

DBMS Material Page No. 9

 Unit – 1
1.4.3 Other Data Models

Hierarchical Model:
The hierarchical data model organizes data in a tree structure. There is a hierarchy of
parent and child data segments. This structure implies that a record can have repeating
information, generally in the child data segments. Data in a series of records, which have a
set of field values attached to it. It collects all the instances of a specific record together as a
record type. These record types are the equivalent of tables in the relational model, and with
the individual records being the equivalent of rows. To create links between these record
types, the hierarchical model uses Parent Child Relationships. These are a 1:N mapping
between record types. This is done by using trees, like set theory used in the relational model,
"borrowed" from maths.
For example, an organization might store information about an employee, such as
name, employee number, department, salary. The organization might also store information
about an employee's children, such as name and date of birth. The employee and children
data forms a hierarchy, where the employee data represents the parent segment and the
children data represents the child segment. If an employee has three children, then there
would be three child segments associated with one employee segment. In a hierarchical
database the parent-child relationship is one to many. This restricts a child segment to having
only one parent segment. Hierarchical DBMSs were popular from the late 1960s, with the
introduction of IBM's Information Management System (IMS) DBMS, through the 1970s

Network Model:
The popularity of the network data model coincided with the popularity of the
hierarchical data model. Some data were more naturally modeled with more than one parent
per child. So, the network model permitted the modeling of many-to-many relationships in
data. In 1971, the Conference on Data Systems Languages (CODASYL) formally defined the
network model.
The basic data-modeling construct in the network model is the set construct. A set
consists of an owner record type, a set name, and a member record type. A member record
type can have that role in more than one set, hence the multiparent concept is supported. An
owner record type can also be a member or owner in another set. The data model is a simple
network, and link and intersection record types (called junction records by IDMS) may exist,
as well as sets between them. Thus, the complete network of relationships is represented by
several pairwise sets; in each set some (one) record type is owner (at the tail of the network
arrow) and one or more record types are members (at the head of the relationship arrow).

DBMS Material Page No. 10

 Unit – 1
Usually, a set defines a 1:M relationship, although 1:1 is permitted. The CODASYL network
model is based on mathematical set theory.

Object/Relational Model:
Object/relational database management systems (ORDBMSs) add new object storage
capabilities to the relational systems at the core of modern information systems. These new
facilities integrate management of traditional fielded data, complex objects such as time-
series and geospatial data and diverse binary media such as audio, video, images, and applets.
By encapsulating methods with data structures, an ORDBMS server can execute comple x
analytical and data manipulation operations to search and transform multimedia and other
complex objects.
As an evolutionary technology, the object/relational (OR) approach has inherited the
robust transaction- and performance-management features of it s relational ancestor and the
flexibility of its object-oriented cousin. Database designers can work with familiar tabular
structures and data definition languages (DDLs) while assimilating new object-management
possibi lities. Query and procedural languages and call interfaces in ORDBMSs are familiar:
SQL3, vendor procedural languages, and ODBC, JDBC, and proprie tary call interfaces are
all extensions of RDBMS languages and interfaces. And the leading vendors are, of course,
quite well known: IBM, Inform ix, and Oracle.

Object-Oriented Model:
Object DBMSs add database functionality to object programming languages. They
bring much more than persistent storage of programming language objects. Object DBMSs
extend the semantics of the C++, Smalltalk and Java object programming languages to
provide full-featured database programming capability, while retaining native language
compatibility. A major benefit of this approach is the unification of the application and
database development into a seamless data model and language environment. As a result,
applications require less code, use more natural data modeling, and code bases are easier to
maintain. Object developers can write complete database applications with a modest amount
of additional effort.
According to Rao (1994), "The object-oriented database (OODB) paradigm is the
combination of object-oriented programming language (OOPL) systems and persistent
systems. The power of the OODB comes from the seamless treatment of both persistent data,
as found in databases, and transient data, as found in executing programs."
In contrast to a relational DBMS where a complex data structure must be flattened out
to fit into tables or joined together from those tables to form the in-memory structure, object

DBMS Material Page No. 11

 Unit – 1
DBMSs have no performance overhead to store or retrieve a web or hierarchy of interrelated
objects. This one-to-one mapping of object programming language objects to database
objects has two benefits over other storage approaches: it provides higher performance
management of objects, and it enables better management of the complex interrelationships
between objects. This makes object DBMSs better suited to support applications such as
financial portfolio risk analysis systems, telecommunications service applications, world
wide web document structures, design and manufacturing systems, and hospital patient
record systems, which have complex relationships between data.

Semi structured Model:

In semi structured data model, the information that is normally associated with a
schema is contained within the data, which is sometimes called ``self-describing''. In such
database there is no clear separation between the data and the schema, and the degree to
which it is structured depends on the application. In some forms of semi structured data there
is no separate schema, in others it exists but only places loose constraints on the data. Semi-
structured data is naturally modeled in terms of graphs, which contain labels, which give
semantics to its underlying structure. Such databases subsume the modeling power of recent
extensions of flat relational databases, to nested databases, which allow the nesting (or
encapsulation) of entities, and to object databases, which, in addition, allow cyclic references
between objects.
Semi structured data has recently emerged as an important topic of study for a variety
of reasons. First, there are data sources such as the Web, which we would like to treat as
databases but which cannot be constrained by a schema. Second, it may be desirable to have
an extremely flexible format for data exchange between disparate databases. Third, even
when dealing with structured data, it may be helpful to view it as semi structured for the
purposes of browsing.

DBMS Material Page No. 12

 Unit – 1
1.5 Database Languages

A database system provides a data definition language to specify the database schema
and a data manipulation language to express database queries and updates. In practice, the
data definition and data manipulation languages are not two separate languages; instead they
simply form parts of a single database language, such as the widely used SQL language.

1.5.1 Data Definition Language (DDL)

A database schema is specified by a set of definitions expressed by a special language
called ‘DDL’. The result of compilation of ‘DDL’ statements is a set of tables that is stored in
a special file called ‘Data Dictionary’. Data dictionary contains metadata (i.e., data about
data). And it is the Database Schema. DDL allows us to specify the storage and access
methods using a special language called data storage and definition language.
The DDL commands in the SQL are CREATE, DROP, ALTER, DESC, RENAME.

1.5.2 Data Manipulation Language (DML)

Data Manipulation Language performs the following operations.
• Insert the Data
• Update the Data
• Delete the Data
• Retrieve the Data
A language, which enables the users to access data. A ‘Query’ is a statement to
retrieve information. The query is executed by query language, which is the part of ‘DML’.
The DML commands in the SQL are INSERT, UPDATE, DELETE, SELECT.

Data Control Language (DCL):

A language, which authenticates users to access data by others. It describes that
Control over the Database. It used to give the Permissions to the Users of the Database. In
SQL We have the commands like GRANT and REVOKE.

DBMS Material Page No. 13

 Unit – 1
1.5.3 Database Access from Application Programs
Application programs are programs that are used to interact with the database.
Application programs are usually written in a host language, such as Cobol, C, C++, or Java.
Examples in a banking system are programs that generate payroll checks, debit accounts,
credit accounts, or transfer funds between accounts.
To access the databasae, DML statements need to be executed from the host language.
There are two ways to do this:
• By providing an application program interface (set of procedures) that can be used to
send DML and DDL statements to the database, and retrieve the results.
The Open Database Connectivity (ODBC) standard defined by Microsoft for use with
the C language is a commonly used application program interface standard. The Java
Database Connectivity (JDBC) standard provides corresponding features to the Java
language.
• By extending the host language syntax to embed DML calls within the host language
program. Usually, a special character prefaces DML calls, and a preprocessor, called
the DML precompiler, converts the DML statements to normal procedure calls in the
host language.

DBMS Material Page No. 14

 Unit – 1
1.6 Database Users & Database Administrators
A primary goal of a database system is to retrieve information from and store new
information in the database. People who work with a database can be categorized as database
users or database administrators.
Database Users:
There are four different types of database-system users, differentiated by the way they
expect to interact with the system.
Naive users:
These users are also called as Unsophisticated Users. They don’t have any type of
knowledge with the system. These users interact with the system by invoking one of the
application programs that have been written previously. For example, a bank teller who needs
to transfer $50 from account A to account B invokes a program called transfer. This program
asks the teller for the amount of money to be transferred, the account from which the money
is to be transferred, and the account to which the money is to be transferred.

Application programmers:
These users are computer professionals who write application programs. Application
programmers can choose from many tools to develop user interfaces. Rapid application
development (RAD) tools are tools that enable an application programmer to construct forms
and reports without writing a program. There are also special types of programming
languages that combine imperative control structures (for example, for loops, while loops and
if-then-else statements) with statements of the data manipulation language.

Sophisticated users:
These users are interacting with the system without writing programs. Instead, they
form their requests in a database query language. They submit each such query to a query
processor, whose function is to break down DML statements into instructions that the storage
manager understands. Analysts who submit queries to explore data in the database fall in this
category. Online analytical processing (OLAP) tools simplify analysts’ tasks by letting them
view summaries of data in different ways.

Specialized users:
These users are sophisticated users who write specialized database applications that
do not fit into the traditional data-processing framework. Among these applications are
computer-aided design systems, knowledge base and expert systems, systems that store data
with complex data types (for example, graphics data and audio data), and environment-

DBMS Material Page No. 15

 Unit – 1
modeling systems. And these users write specialized application program for queries, which
cannot be answered directly.

Database Administrator:
One of the main reasons for using DBMSs is to have central control of both the data
and the programs that access those data. A person who has such central control over the
system is called a database administrator (DBA). The functions of a DBA include:
• Schema definition. The DBA creates the original database schema by executing a set
of data definition statements in the DDL.
• Storage structure and access-method definition.
• Schema and physical-organization modification. The DBA carries out changes to the
schema and physical organization to reflect the changing needs of the organization, or
to alter the physical organization to improve performance.
• Granting of authorization for data access. By granting different types of authorization,
the database administrator can regulate which parts of the database various users can
access. The authorization information is kept in a special system structure that the
database system consults whenever someone attempts to access the data in the system.
• Routine maintenance. Examples of the database administrator’s routine maintenance
activities are:
o Periodically backing up the database, either onto tapes or onto remote servers,
to prevent loss of data in case of disasters such as flooding.
o Ensuring that enough free disk space is available for normal operations, and
upgrading disk space as required.
o Monitoring jobs running on the database and ensuring that performance is not
degraded by very expensive tasks submitted by some users.

DBMS Material Page No. 16

 Unit – 1
1.7 Transaction Management

A transaction is said to be as execution of the User Program in the DBMS.

A Transaction can be defined as collection of operations that form into a single logical
unit of work.

The transaction is the execution of a program that access or changes the contents of the
database.

Example: Transferring of funds from one account to another account is a Transaction.

Properties of Transaction: Every transaction will have 4 properties.

Atomicity: This property ensures a transaction is an atomic unit of processing. That is the
transaction is either perform completely or not perform at all.
Consistency: A correct execution of a transaction must take the database from one consistent
state to another consistent state.
Isolation: A transaction should not make its updates visible to other transactions until it is
committed.
Durability: Once the transaction changes the database and the changes are committed, these
changes must never be lost because of sub sequent failures.

DBMS Material Page No. 17

 Unit – 1
1.8 Database System Structure

A database system is partitioned into modules that deal with each of the
responsibilities of the overall system. The functional components of a database system can be
broadly divided into the storage manager and the query processor components.
The storage manager is important because databases typically require a large amount
of storage space. Some Big organizations Database ranges from giga bytes to tera bytes. So
the main memory of computers cannot store this much information, the information is stored
on disks. Data are moved between disk storage and main memory as needed.
The query processor also very important because it helps the database system simplify
and facilitate access to data. So quick processing of updates and queries is important. It is the
job of the database system to translate updates and queries written in a nonprocedural
language, at the logical level, into an efficient sequence of operations at the physical level.

Database System Structure

Data Base System Structure

DBMS Material Page No. 18

 Unit – 1
1.8.1 Storage Manager
A storage manager is a program module that provides the interface between the low-
level data stored in the database and the application programs and queries submitted to the
system. The storage manager is responsible for the interaction with the file manager. The
storage manager translates the various DML statements into low-level file-system commands.
Thus, the storage manager is responsible for storing, retrieving, and updating data in the
database.
Storage Manager Components:
Authorization and integrity manager: which tests for the satisfaction of integrity
constraints and checks the authority of users to access data.
Transaction manager: which ensures that the databasef remains in a consistent (correct)
state despite system failures, and that concurrent transaction executions proceed without
conflicting.
File manager: which manages the allocation of space on disk storage and the data structures
used to represent information stored on disk.
Buffer manager: which is responsible for fetching data from disk storage into main memory.
The storage manager implements several data structures as part of the physical system
implementation. Data files are used to store the database itself. Data dictionary is used to
stores metadata about the structure of the database, in particular the schema of the database.
1.8.2 Query Processor
Query Processor Components:
DDL interpreter: It interprets DDL statements and records the definitions in the data
dictionary.
DML compiler: It translates DML statements in a query language into an evaluation plan
consisting of low-level instructions that the query evaluation engine understands.
Query evaluation engine: It executes low-level instructions generated by the DML
compiler.

Application Architectures:
Most users of a database system today are not present at the site of the database
system, but connect to it through a network. We can therefore differentiate between client
machines, on which remote database users’ work, and server machines, on which the
database system runs. Database applications are usually partitioned into two or three parts.
That is two – Tier Architecture, Three – Tier Architecture.

DBMS Material Page No. 19

 Unit – 1
Two-tier architecture:
The application is partitioned into a component that resides at the client machine,
which invokes database system functionality at the server machine through query language
statements. Application program interface standards like ODBC and JDBC are used for
interaction between the client and the server.
Three-tier architecture:
The client machine acts as merely a front end and does not contain any direct database calls.
Instead, the client end communicates with an application server, usually through a forms
interface. The application server in turn communicates with a database system to access data.
The business logic of the application, which says what actions to carry out under what
conditions, is embedded in the application server, instead of being distributed across multiple
clients. Three-tier applications are more appropriate for large applications, and for
applications that run on the World Wide Web.

Two – Tier and Three – Tier Architectures

DBMS Material Page No. 20