2

Unit- 1
INTRODUCTION TO DBMS
Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS
 What Is DBMS?
2

 A database management system (DBMS) is system software for

creating and managing database.
 The DBMS provides users and programmers with a systematic way to
create, retrieve, update and manage data.
 The DBMS essentially serves as an interface between
the database and end users or application programs, ensuring that
data is consistently organized and remains easily accessible.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 What Is DBMS?
3

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Database System Architecture
4

 The design of a DBMS depends on its architecture.

 It can be centralized or decentralized or hierarchical. The architecture of a
DBMS can be seen as either single tier or multi-tier.
 This architecture is a three layered architecture the bottom layer consist of
the Database, middle layer is DBMS and top layer is a view.
 This architecture describe how the interaction between user and various
components of DBMS system is done.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Database System Architecture
5
Application End User DDL

DML pre Compiler Query Processor

DML Compiler DDL Compiler

Query Evaluation Engine

Stored Data Manager

Transaction Manager Buffer Manager File Manager Authorization Manager

Database

Prepared By: Prof. V. K.Data

Wani Unit No. 1: Introduction to DBMS
Data Dictionary
Files Indices
 Database System Architecture
6

1. DBMS Layer: is a middle layer consisting of two major components as follow.

A. Query Processor Components: Responsible for executing users query
Following are the components of the storage manager;
 DML Pre-compiler: It translates DML statements in a query language into
low level instructions that query evaluation engine understands.
 Embedded DML Pre-compiler: It converts DML statements embedded in
an application program to normal procedure calls in the host language.
 DDL Interpreter: It interprets the DDL statements and records them in a
set of tables containing meta data or data dictionary.
 Query Evaluation Engine: It executes low-level instructions generated by
the DML compiler.
Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS
 Database System Architecture
7

Storage Manager Components: A storage manager is responsible for storing,

retrieving and updating data in the database. Following are the components of
the storage manager;
Authorization and Integrity Manager: It tests the integrity constraints and
checks the authorization of users to access data.
Transaction Manager: It ensures that no kind of change will be brought to the
database until a transaction has been completed totally.
File Manager: It manages the allocation of space on disk storage and the data
structures used to represent information stored on disk.
Buffer Manager: It decides which data is in need to be cached in main memory
and then fetch it up in main memory.
Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS
 Database System Architecture
8

Database Layer: it is the Bottom layer consisting of following sub components.

Data Dictionary: data dictionary is a file or a set of files that contains a

database's metadata. The data dictionary contains records about other objects
in the database, such as data ownership, data relationships to other objects, and
other data.
Data Files: A data file is file which stores data to be used by a application or
user .
DBMS Indexing: We know that data is stored in the form of records. Every
record has a key field, which helps it to be recognized uniquely.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 View Levels of DBMS Architecture
9

View Levels of DBMS Architecture also called as Level of Data Abstraction in

DBMS describe the various views and levels of data abstraction in DBMS system
which are as Physical Level, Conceptual Level and External Level.
Physical Level:
 Physical level describes the physical storage structure of data in database, as
well it also describe how the data is stored and retrieve in database.
 It also describe compression and encryption techniques applied on data.
 It is also known as Internal Level.
 This level is very close to physical storage of data.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 10

View Levels of
DBMS
Architecture

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 View Levels of DBMS Architecture
11
2. Conceptual Level: also called logical or global level
 It describes the structure of the whole database for a group of users.
 It also describe how the data will be appeared to various user and
relationship between various data.
3. External Level: is also called view level
 It is related to the data which is viewed by individual end users.
 This level includes a no. of user views or external schemas.
 This level is closest to the user. External view describes the segment of the
database that is required for a particular user group and hides the rest of the
database from that user group.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Data Models in DBMS
12

 A data model organizes elements of data and standardizes how they relate
to one another and to properties of the real world entities.
 Data models describe how the data in database is get organized or stored
and how it is related with each other’s.
 the different types of data models are as follow.
1. Relation model 7. Entity relation Model
2. Network model 8. Flat data model
3. Hierarchical model 9. Semi structured model
4. Object oriented model 10. Associative model
5. Context data model 11. Record base model
6. Object relation model
Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS
 Relational Data Model
13
 This model is the most popular model and the most extensively used model.
 In this data can be stored in the tables and this storing is called as relation.
 Each row in a relation contains unique value and it is called as tuple, each
column contains value from same domain and it is called as attribute.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Relational Data Model
14

Advantages
 Structural independence – changes in the relational data structure do
not affect the DBMS’s data access in any way
 Improved conceptual simplicity by concentrating on the logical view
 Easier database design, implementation, management, and use
 Powerful database management system.

Disadvantages
 Can facilitate poor design and implementation

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Network Data Model
15
 This model has entities which are organized in a graphical representation.
 Its distinguishing feature is that the schema is viewed as a graph in which
object types are nodes and relationship types are arcs.
 It can preserve one to many or many to many relation.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Network Data Model
16

Advantages
 Provide very efficient "High-speed" retrieval.
 Simplicity The network model is conceptually simple and easy to design.
 Ability to handle more relationship types The network model can handle the
one-to-many and many-to-many relationships.
 Data Integrity In a network model, no member can exist without an owner.
 Data Independence.

Disadvantages
 System complexity: data are accessed one record at a time.
 Making structural modifications to the database is very difficult as the data
access method is navigational.
 Any changes made to the database structure require the application
programs to be modified before they can access data.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Hierarchical Data Model
17

 this model has one parent entity with several children entity but at the top
we should have only one entity called root.
 For example, department is the parent entity called root and it has several
children entities like students, professors and many more.
 In This model data are organized into a tree-like structure.
 The data are stored as records which are connected to one another through
links. It preserves one to many relations.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Distributed Properties of Ubicomp
18

Advantages
 Simplicity
 Security
 Database Integrity
 Efficiency

Disadvantages
 Complexity of Implementation
 Difficulty in Management
 Complexity of Programming
 Poor Portability
 Database Management Problems

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Object oriented Data Model
19

 Object oriented data model can hold the audio, video and graphic files.
 OODBMS should be used when there is a business need, high performance
required, and complex data is being used.
 It can represent the data in real world entity called Object.

Advantages:
 Suitable for application expecting high performance.
 Due to the object oriented nature of the database model, it is much
simpler to approach a problem
Disadvantages:
 complex data is being used
 Complex relations are used
Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS
 Context-Awareness Properties of Ubicomp
20

Object relation Data Model:

 Object relation model is a very powerful model but coming to its design it is quiet
complex.
 This complexity is not problem because it gives efficient results and widespread with
huge applications. It has a feature which allows working with other models like
working with the very known relation model.
 Advantages of Object Relational model is inheritance The Object Relational data
model allows its users to inherit objects, tables etc.
 The object relational data model can get quite complicated and difficult to handle at
times as it is a combination of the Object oriented data model and Relational data
model and utilizes the functionalities of both of them.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Object Relation Data Model
21

 Object relation model is a very powerful model but coming to its design it is
quiet complex.
 This complexity is not problem because it gives efficient results and
widespread with huge applications.
 The Object Relational data model allows its users to inherit objects, tables .
 An inherited object contains new attributes as well as the attributes that
were inherited.
 The object relational data model can get quite complicated and difficult to
handle at times as it is a combination of the Object oriented data model and
Relational data model and utilizes the functionalities of both of them.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Context Data Model
22

 This model is a flexible model because it is a collection of many data models.

 It is a collection of the data models like object oriented data model, network
model, semi structured model.
 In this different types of works can be done due to the versatility of it.
 A context model defines how context data are structured and maintained It
plays a key role in supporting efficient context management.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Associative Model
23
 This model has a division property, it divides the real world things about
which data is to be recorded in two sorts i.e. between entities and
associations.
 This model does the division for dividing the real world data to the entities
and associations.
 The associative model of data is a data model for database systems.
 These models involve encompassing attributes about a thing, such as a car,
in a record structure.
 In the associative model, everything which has “discrete independent
existence” is model as an entity, and relationships between them are
modelled as associations.
Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS
 Semi structured, Record base & Flat Data Model
24

Semi structured Data Model: Semi structured data model is a self-describing

data model, in this the information that is normally associated with a scheme is
contained within the data and this property is called as the self-describing
property.

Record base model: This model specify the overall structure of database. Like
Object based model, they also describe data at the conceptual and view levels. T

Flat Data Model: The flat model is the earliest, simplest data model. It simply
lists all the data in a single table, consisting of columns and rows. In order to
access or manipulate the data, the computer has to read the entire flat file into
memory, which makes this model inefficient for all but the smallest data sets.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Entity Relation Model
25

 The ER model defines the conceptual view of a database.

 It works around real-world entities and the associations among them.
 At view level, the ER model is considered a good option for designing
databases.
 the people, places, and things about which data points are stored are
referred to as entities,
 each entity has certain attributes that together make up their domain.
 The cardinality, or relationships between entities, are also mapped.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Entity Relation Diagram

26

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Entity Relation Diagram
27

An entity–relationship model describes interrelated things of interest in a specific

domain of knowledge.
 The ER or (Entity Relational Model) is a high-level conceptual data model diagram.
Entity-Relation model is based on the notion of real-world entities and the
relationship between them

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Components of E-R Diagram
28

Name Symbol Meaning

Entity Any real-world object can be represented as an entity
about which data can be stored in a database
Weak entity A weak entity does not have a primary key attribute &
depends on other entity or foreign key attribute.
Attributes Entities are represented by means of their properties,
called attributes.

Types of Attributes

Simple Simple attributes are atomic values, which cannot

attribute be divided further.
Derived the attributes that do not exist in the database, but
attribute their values are derived from other attributes
Multi-value Multi-value attributes may contain more than one
attribute values. For example phone number
Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS
 Components of E-R Diagram
29

Name Symbol Meaning

Single-value Single-value attributes contain single value.
attribute

Composite Composite attributes are made of more than one

attribute simple attribute. They Can be Divided further.

Key Attribute Representing Primary Key for Entity.

Attributes

Relationship Relationship is nothing but an association among

two or more entities

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Components of E-R Diagram
30

Name Symbol Meaning

Mapping It defines the number of entities in one entity set, which can be
Cardinalities associated with the number of entities of other set via relationship
set.
Mapping Cardinalities Types

One-to-one One entity from entity set A can be associated with

at most one entity of entity set B and vice versa.

One-to- One entity from entity set A can be associated with

many more than one entities of entity set B

Many-to- More than one entities from entity set A can be

one associated with at most one entity of entity set B
Many-to- Many entity from A can be associated with more
many than one entity from B and vice versa.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Some of Additional Notations of Cardinalities
31

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Components of E-R Diagram
32

Name Meaning
Entity-Set & Key is an attribute or collection of attributes that uniquely
Keys identifies an entity among entity set.
Cardinalities Types
Super Key A set of attributes (one or more) that collectively identifies an
entity in an entity set.
Candidate The minimal set of attribute which can uniquely identify a tuple
Key is known as candidate key.
Primary A primary key is one of the candidate keys chosen by the
Key database designer to uniquely identify the entity set.
Foreign If an attribute is depend on the attribute present as values of
Key some other attribute for its identity, it will be referred as foreign
key
Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS
 Composite Attribute
33

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Multi-value attribute

34

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Derived attribute
35

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Simple & Single-value attribute
36

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 ER Diagram

37

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Participation Constraints in ER Diagram
38

Total Participation − Each entity is involved in the relationship. Total

participation is represented by double lines.
Partial participation − Not all entities are involved in the relationship. Partial
participation is represented by single lines.

Degree of Relationship: The number of participating entities in a relationship

defines the degree of the relationship.
Binary = degree 2, Ternary = degree 3, n-ary = degree
Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS
 Enhanced ER Model

39

 EER is a high-level data model that incorporates the extensions to the

original ER model.
 It is a diagrammatic technique for displaying concepts like specialization,
generalization, Union or Category, Aggregation, Sub Class and Super Class
 These concepts are used when the comes in EER schema and the resulting
schema diagrams called as EER Diagrams.
 EER creates a design more accurate to database schemas.
 It reflects the data properties and constraints more precisely.
 It includes all modeling concepts of the ER model.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Generalization in ER-R Diagram

40

 The process of generalizing entities, where the generalized entities contain

the properties of all the generalized entities, is called generalization.
 In generalization, a number of entities are brought together into one
generalized entity based on their similar characteristics.
 It is a Bottom Up approach, in which more than one lower entity can be
marged into two one top level entity.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Specialization in ER-R Diagram

41
 Specialization is the opposite of generalization. In specialization, a group of
entities is divided into sub-groups based on their characteristics.
 specialization is a process that defines a group entities which is divided into
sub groups based on their characteristic.
 It is a top down approach, in which one higher entity can be broken down
into two lower level entity.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Inheritance in ER-R Diagram

42

 We use all the above features of ER-Model in order to create classes of

objects in object-oriented programming.
 The details of entities are generally hidden from the user; this process
known as abstraction.
 Inheritance is an important feature of Generalization and Specialization.
 It allows lower-level entities to inherit the attributes of higher-level entities.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Inheritance in ER-R Diagram

43

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Sub Class and Super Class
44

Sub class and Super class relationship leads the concept of Inheritance.
 The relationship between sub class & super class is denoted with
Symbol .
Super Class: Super class is an entity type that has a relationship with one or
more subtypes. An entity cannot exist in database merely by being member of
any super class.
For example: Shape super class is having sub groups as Square, Circle,
Triangle.
Sub Class: Sub class is a group of entities with unique attributes. Sub class
inherits properties and attributes from its super class. For example: Square,
Circle, Triangle are the sub class of Shape super class.
Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS
 Sub Class and Super Class

45

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Category or Union in ER-R Diagram
46

 Category represents a single super class or sub class relationship with

more than one super class.
 It can be a total or partial participation.
 example Car booking, Car owner can be a person, a bank (holds a
possession on a Car) or a company. Category (sub class) → Owner is a
subset of the union of the three super classes → Company, Bank, and
Person.
 A Category member must exist in at least one of its super classes.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Category or Union in ER-R Diagram
47

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Aggregation in ER-R Diagram
48

 Aggregation is a process that represents a relationship between a whole

object and its component parts.
 It abstracts a relationship between objects and viewing the relationship as
an object.
 It is a process in which two entity is treated as a single entity.
 In the example, the relation between College and Course is acting as an
Entity in Relation with Student.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Aggregation in ER-R Diagram
49

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Rules for Converting ER Diagram to Tables
50

 An ER diagram is a pictorial representation of the information that canbe

captured by a database.
 Such a “picture” serves two purposes:
 It allows database professionals to describe an overall design concisely yet
accurately.
 (Most of) it can be easily transformed into the relational schema
 There different rules for converting ER Diagram to Relational Model or
Tables.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Rules for Converting ER Diagram to Tables
51

Rule-01: For Strong Entity Set With Only Simple Attributes:

 A strong entity set with only simple attributes will require only one table in
relational model.
 Attributes of the table will be the attributes of the entity set.
 The primary key of the table will be the key attribute of the entity set.

Roll_no Name Sex

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Rules for Converting ER Diagram to Tables
52
Rule-02: For Strong Entity Set With Composite Attributes:
 A strong entity set with any number of composite attributes will require only
one table in relational model.
 While conversion, simple attributes of the composite attributes are taken
into account and not the composite attribute itself.

First-Name Last-Name

Roll_no First-name Last-Name Sex

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Rules for Converting ER Diagram to Tables
53
Rule-03: For Strong Entity Set With Multi Valued Attributes:
 A strong entity set with any number of multi valued attributes will require
two tables in relational model.
 One table will contain all the simple attributes with the primary key.
 Other table will contain the primary key and all the multi valued attributes.

Roll_no city

Roll_no Mobile-no

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Rules for Converting ER Diagram to Tables
54
Rule-04: Translating Relationship Set into a Table- A relationship set will
require one table in the relational model. Attributes of the table are
 Primary key attributes of the participating entity sets
 Its own descriptive attributes if any.
 Set of non-descriptive attributes will be the primary key

Emp_no Dept_id since

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Rules for Converting ER Diagram to Tables
55
Rule-05: For Binary Relationships With Cardinality Ratios: The following
four cases are possible
Case-01: Binary relationship with cardinality ratio m:n : in this case
separate table for relationship will be required which will include the attributes
which describe the identity of relation entities i.e. primary key from both
entities.

Here, three tables will be required:

1. A ( a1 , a2 ) 2. R ( a1 , b1 ) 3. B ( b1 , b2 )

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Rules for Converting ER Diagram to Tables
56
Case-02: For Binary Relationship With Cardinality Ratio 1:n: in this case
separate table for relationship is not required. The table for Relationship can be
merged with entity having many relation. For binary relationship with
cardinality ratio either m : 1 or 1 : n , always remember “many side will
consume the relationship. Here, combined table will be drawn for the entity set
B and relationship set R.

Here, two tables will be required:

1. A ( a1 , a2 ) 2. BR ( b1 , b2, a1 )
Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS
 Rules for Converting ER Diagram to Tables
57
Case-03: For Binary Relationship With Cardinality Ratio m:1: in this case
separate table for relationship is not required. The table for Relationship can be
merged with entity having many relation. For binary relationship with
cardinality ratio either m : 1 or 1 : n , always remember “many side will
consume the relationship” . Here, combined table will be drawn for the entity
set A and relationship set R.

Here, two tables will be required:

1. AR ( a1 , a2, b1 ) 2. B ( b1 , b2)
Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS
 Rules for Converting ER Diagram to Tables
58
Case-04: For Binary Relationship With Cardinality Ratio 1:1 For binary
relationship with cardinality ratio 1 : 1 , two tables will be required. You can
combine the relationship set with any one of the entity sets. Here, two tables
will be required. Either combine ‘R’ with ‘A’ or ‘B’

Way-01: AR ( a1 , a2 , b1 ) & B ( b1 , b2 )
Way-02: A ( a1 , a2 ) & BR ( a1 , b1 , b2 )

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Rules for Converting ER Diagram to Tables
59
Rule-06: For Binary Relationship With Both Cardinality Constraints &
Participation Constraints: Cardinality constraints will be implemented as
discussed in Rule-05. Because of the total participation constraint, foreign key
acquires NOT NULL constraint i.e. now foreign key cannot be null.
Case-01: For Binary Relationship With Cardinality Constraint and Total
Participation Constraint From One Side

Here, two tables will be required:

1. AR ( a1 , a2, b1 ) 2. B ( b1 , b2 )
Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS
 Rules for Converting ER Diagram to Tables
60
 Case-02: For Binary Relationship With Cardinality Constraint and Total
Participation Constraint From Both Sides:
 If there is a key constraint from both the sides of an entity set with total
participation, then that binary relationship is represented using only single
table.

Here, Only one table is required. 1. ARB ( a1 , a2 , b1 , b2 )

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Rules for Converting ER Diagram to Tables
61
Rule-07: For Binary Relationship With Weak Entity Set-: Weak entity set
always appears in association with identifying relationship with total
participation constraint.

Here, two tables will be required:

1. A ( a1 , a2 ) 2. BR ( a1 , b1 , b2 )

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Database Users & architecture of DBA
62
Database Users: Database users are the one who really use and take the benefits of
database. There will be different types of users depending on their need and way of
accessing the database.
1. Application Programmers - They are the developers who interact with the
database by means of DML queries.
2. Sophisticated Users - They are database developers, who write SQL queries to
select/insert/delete/update data. They do not use any application or programs to
request the database. They directly interact with the database by means of query
language like SQL.
3. Specialized Users - These are also sophisticated users, they write special database
application programs. They are the developers who develop the complex programs
to the requirement.
4. Stand-alone Users - These users will have stand –alone database for their personal
use. These kinds of database will have readymade database packages which will
have menus and graphical interfaces.
5. Native Users - these are the users who use the existing application to interact with
the database. For example, online library system, ticket booking systems, ATMs etc.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Database Users & Architecture of DBA
63
Types of DBA: There are different kinds of DBA depending on the responsibility that he
owns.
1. Administrative DBA - This DBA is mainly concerned with all administrative tasks
like installing, & maintaining DBMS servers. His prime tasks are installing, backups,
recovery, security, replications, memory management, configurations and tuning.
2. Development DBA - He is responsible for creating queries and procedure for the
requirement.
3. Database Architect - Database architect is responsible for creating and maintaining
the users, roles, access rights, tables, views, constraints and indexes.
4. Data Warehouse DBA -DBA should be able to maintain the data and procedures
from various sources in the data warehouse. These sources can be files, COBOL, or
any other programs.
5. Application DBA -He acts like a bridge between the application program and the
database. He ensures all the activities from installing, upgrading, and patching,
maintaining, backup, recovery to executing the records works without any issues.
6. OLAP DBA - He is responsible for installing and maintaining the database in OLAP
systems. He maintains only OLAP databases.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Database Users & architecture of DBA
64
Types of DBA: There are different kinds of DBA depending on the responsibility that he
owns.
1. Administrative DBA - This DBA is mainly concerned with all administrative tasks
like installing, & maintaining DBMS servers. His prime tasks are installing, backups,
recovery, security, replications, memory management, configurations and tuning.
2. Development DBA - He is responsible for creating queries and procedure for the
requirement.
3. Database Architect - Database architect is responsible for creating and maintaining
the users, roles, access rights, tables, views, constraints and indexes.
4. Data Warehouse DBA -DBA should be able to maintain the data and procedures
from various sources in the data warehouse. These sources can be files, COBOL, or
any other programs.
5. Application DBA -He acts like a bridge between the application program and the
database. He ensures all the activities from installing, upgrading, and patching,
maintaining, backup, recovery to executing the records works without any issues.
6. OLAP DBA - He is responsible for installing and maintaining the database in OLAP
systems. He maintains only OLAP databases.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Database Administrators:
65
Database Administrators:
 The life cycle of database starts from designing, implementing to
administration of it.
 A database for any kind of requirement needs to be designed perfectly so
that it should work without any issues.
 Once all the design is complete, it needs to be installed. Once this step is
complete, users start using the database.
 The database grows as the data grows in the database. When the database
becomes huge, its performance comes down.
 Also accessing the data from the database becomes challenge.
 These administration and maintenance of database is taken care by
database Administrator DBA.
 A DBA has many responsibilities. A good performing database is in the hands
of DBA.
 The various phases of DBA are

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Database Administrators:
66

 Installing and upgrading the DBMS Servers: - DBA is responsible for installing a
new DBMS server for the new projects. He is also responsible for upgrading these
servers as there are new versions comes in the market or requirement.
 Design and implementation: - He should be able to decide proper memory
management, file organizations, error handling, log maintenance for the database.
 Performance tuning: - Since database is huge and it will have lots of tables, data,
constraints & indices, there will be variations in the performance from time to time.
 Migrate database servers: - Sometimes, users using oracle would like to shift to
SQL server or Netezza. It is the responsibility of DBA to make sure that migration
happens without any failure, and there is no data loss.
 Backup and Recovery: - Proper backup and recovery programs needs to be
developed by DBA and has to be maintained him.
 Security: - DBA is responsible for creating various database users and roles, and
giving them different levels of access rights.
 Documentation: - DBA should be properly documenting all his activities so that if
he quits or any new DBA comes in, he should be able to understand the database
without any effort.
Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS
 Legacy System
67
 The Software system which are developed long year ago for an organisation
but still they are in use are called as legacy system.
 There is a significant business risk in simply scrapping a legacy system &
replacing it with a system that has developed using modern technology.
 During their lifetime they have undergone major changes which may not
have been documented.
 Legacy systems are not simply old software systems. Legacy systems are
socio-technical computer-based systems so they include software,
hardware, data and business processes.
 Changes to one part of the system inevitably involve further changes to
other components.
Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS
 The different parts of a legacy system
68

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 The different parts of a legacy system
69

 System hardware: In many cases, legacy systems have been written for
mainframe hardware which is no longer available, which is expensive to
maintain and which may not be compatible with current organisational IT
purchasing policies.
 Support software: The legacy system may rely on a range of different
support software from the operating system and utilities provided by the
hardware manufacturer.
 Application software: As I discuss later, the application system which
provides the business services is usually composed of a number of separate
programs which have been developed at different times.
 Application data: These are the data which are processed by the
application system.
 Business processes: These are processes which are used in the business
to achieve some business objective.
 Business policies and rules: These are definitions of how the business
should be carried out and constraints on the business.
Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS
 Layered model of a legacy system
70

 An alternative way of looking at these different components of a legacy

system is as series of layers.
 Each layer depends on the layer immediately below it and interfaces with
that layer.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Legacy application system
71

 The application software in a legacy system is not a single application

program but usually includes a number of different programs.
 The system may have started as a single program processing one or two
data files but, over time, changes may have been implemented by adding
new programs which share the data and which communicate with other
programs in the system.
 Similarly, the initial system data files are added to as new information is
required.
 Different programs share data files so that changes to one program that
affect data inevitably result in changes to other programs.

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Legacy application system
72

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Database-centred systems
73

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS

 Thank You
74

Prepared By: Prof. V. K. Wani Unit No. 1: Introduction to DBMS