Student

Teacher

Employee

Library

Student Program

Teacher Program

Employee Program

Library Program

Reports

Reports

Reports

Reports

Database Systems versus File Systems

Considered the scenario in your campus or university recording keeping system, they need to make record for the students, teacher, employee, and book etc. all these data can be stored in the sequential file like notepad or any other text editor. We need separate file for student, teacher, book and staff so that user able to manipulate these data in right time. Files were best storage medium before the introduced of DBMS and may enterprise kept their record in flat files.A collection of application programs that perform services for the end-users such as the production of reports. Each program defines and manages its own data.Typical file-processing system is supported by a conventional operating system. 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. To keep the record in flat file has numerous disadvantages that are listed below:

Data file Application Program Users

Fig. File oriented Approach.o Data redundancy and inconsistency .

Since different programmers create the files and application programs over a long period, the various files are likely to have different formats and the programs may be written in several programming languages. Moreover, the same information may be duplicated in several places (files). For example, the address and telephone number of a particular student may appear in a file that consists of marks sheet records and in a file that consists of Sport 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 student address may be reflected in mark sheet records but not elsewhere in the system.

o Difficulty in accessing data. Suppose that one of the campus director needs to find out the names of all student who live within a particular area. The director asks the data-processing department to generate such a list. Because the designers of the original system did not anticipate this request, there is no application program on hand to meet it. So it is difficulty in retrieving data on time.

Student Program

Teacher Program

Employee Program

Book Program

Reports

Reports

Reports

Reports

Database

Student TableTeachers TableEmployee Table

Book Table

DatabaseManagementSystem

o 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.

o Integrity problems The data values stored in the database must satisfy certain types of consistency constraints. For example, the money value for registration form a campus may never fall below a prescribed amount (say, 2500). 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.

o 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 Rs 50 from account A to account B. If a system failure occurs during the execution of the program, it is possible that the Rs 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.

o 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 Rs 500. If two customers withdraw funds (say Rs 50 and Rs 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.

o 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. Data file Application Program Users

Fig. DBMS oriented Approach.o Fixed queries/proliferation of application programs

View of DataA database system is a collection of interrelated files and a set of programs that allow users to access and modify these files. A major purpose of a database system is to provide users with an abstract view of the data. That is, the system hides certain details of how the data are stored and maintained.

The Three-Schema ArchitectureThe goal of the three-schema architecture, illustrated in above Figure, is to separate the user applications from the physical database. In this architecture, schemas can be defined at the following three levels:1. The internal (Physical) level has an internal schema, which describes the physical storage structure of the database. The internal schema uses a physical data model and describes the complete details of data storage and access paths for the database.2. The conceptual (Logical) level has a conceptual schema, which describes the structure of the whole database for a community of users. The conceptual schema hides the details of physical storage structures and concentrates on describing entities, data types, relationships, user operations, and constraints.Usually, a representational data model is used to describe the conceptual schema when a database system is implemented. This implementation conceptual schema is often based on a conceptual schema design in a high-level data model.3. The external or view level includes a number of external schemas or user views. Each external schema describes the part of the database that a particular user group is interested in and hides the rest of the database from that user group. As in the previous level, each external schema is typically implemented using a representational data model, possibly based on an external schema design in a high-level data model

Fig. The Three-Schema Architecture

To understand the three-schema architecture, consider the three levels of the BOOK file in Online Book database as shown in bellow Figure. In this figure, two views (view 1 and view 2) of the BOOK file have been defined at the external level. Different database users can see these views. The details of the data types are hidden from the users. At the conceptual level, the BOOK records are described by a type definition. The application programmers and the DBA generally work at this level of abstraction. At the internal level, the BOOK records are described as a block of consecutive storage locations such as words or bytes. The database users and the application programmers are not aware of these details; however, the DBA may be aware of certain details of the physical organization of the data.

INTANCES, SCHEMAS AND SUBSCHEMA in DBMS Database changes over time when information is inserted or deleted. The collection of information stored in the database at a particular moment is called an instance of the database. The overall design of the database is called the database schema. A schema diagram, as shown above, displays only names of record types (entities) and names of data items (attributes) and does not show the relationships among the various files.

The schema will remain the same while the values filled into it change from instant to instant. When the schema framework is filled in with data item values, it is referred as an instance of the schema. The data in the database at a particular moment of time is called a database state or snapshot, which is also called the current set of occurrences or instances in the database In other words, "the description of a database is called the database schema, which is specified during database design and is not expected to change frequently". A displayed schema is called a schema diagram.

A schema diagram displays only some aspects of a schema, such as the number of record types and data items, and some types of constraints. Other aspects are not specified in the schema diagram. It does not specify the data type of each data item and the relationships among the various files. SubschemaA subschema is a subset of the schema and inherits the same property that a schema has. The plan (or scheme) for a view is often called subschema. Subschema refers to an application programmer's (user's) view of the data item types and record types, which he or she uses. It gives the users a window through which he or she can view only that part of the database, which is of interest to him. Therefore, different application Data abstractionOne fundamental characteristic of the database approach is that it provides some level of data abstraction. Data abstraction generally refers to the suppression of details of data organization and storage, and the highlighting of the essential features for an improved understanding of data. One of the main characteristics of the database approach is to support data abstraction so that different users can perceive data at their preferred level of detail.Data modelA collection of concepts that can be used to describe the structure of a database provides the necessary means to achieve this abstraction. By structure of a database we mean the data types, relationships, and constraints that apply to the data.

o Hierarchical Database Model Hierarchical Database model is one of the oldest database models, dating from late 1950s. One of the first hierarchical databases Information Management System (IMS) was developed jointly by North American Rockwell Company and IBM. This model is like a structure of a tree with the records forming the nodes and fields forming the branches of the tree. The hierarchical model organizes data elements as tabular rows, one for each instance of entity. Consider a company's organizational structure. At the top we have a General Manager (GM). Under him we have several Deputy General Managers (DGMs). Each DGM looks after a couple of departments and each department will have a manager and many employees. When represented in hierarchical model, there will be separate rows for representing the GM, each DGM, each department, each manager and each employee. The row position implies a relationship to other rows. A given employee belongs to the department that is closest above it in the list and the department belongs to the manager that is immediately above it in the list and so on as shown.

Advantages1. Simplicity Data naturally have hierarchical relationship in most of the practical situations. Therefore, it is easier to view data arranged in manner. This makes this type of database more suitable for the purpose. 2. Security These database systems can enforce varying degree of security feature unlike flat-file system. 3. Database Integrity Because of its inherent parent-child structure, database integrity is highly promoted in these systems. 4. Efficiency: The hierarchical database model is a very efficient, one when the database contains a large number of I: N relationships (one-to-many relationships) and when the users require large number of transactions, using data whose relationships are fixed.Disadvantages1. Complexity of Implementation: The actual implementation of a hierarchical database depends on the physical storage of data. This makes the implementation complicated. 2. Difficulty in Management: The movement of a data segment from one location to another cause all the accessing programs to be modified making database management a complex affair. 3. Complexity of Programming: Programming a hierarchical database is relatively complex because the programmers must know the physical path of the data items. 4. Poor Portability: The database is not easily portable mainly because there is little or no standard existing for these types of database. 5. Database Management Problems: If you make any changes in the database structure of a hierarchical database, then you need to make the necessary changes in all the application programs that access the database. Thus, maintaining the database and the applications can become very difficult. 6. Lack of structural independence: Structural independence exists when the changes to the database structure does not affect the DBMS's ability to access data. Hierarchical database systems use physical storage paths to navigate to the different data segments. So, the application programs should have a good knowledge of the relevant access paths to access the data. So, if the physical structure is changed the applications will also have to be modified. Thus, in a hierarchical database the benefits of data independence are limited by structural dependence. 7. Programs Complexity: Due to the structural dependence and the navigational structure, the application programs and the end users must know precisely how the data is distributed physically in the database in order to access data. This requires knowledge of complex pointer systems, which is often beyond the grasp of ordinary users (users who have little or no programming knowledge). 8. Operational Anomalies: As discussed earlier, hierarchical model suffers from the Insert anomalies, Update anomalies and Deletion anomalies, also the retrieval operation is complex and asymmetric, thus hierarchical model is not suitable for all the cases. 9. Implementation Limitation: Many of the common relationships do not conform to the l:N format required by the hierarchical model. The many-to-many (N:N) relationships, which are more common in real life are very difficult to implement in a hierarchical model.

o 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 multi parent concept is supported. Network model is a collection data in which records are physically linked through linked lists .A DBMS is said to be a Network DBMS if the relationships among data in the database are of type many-to-many. The Relationship among many-to-many appears in the form of a network. Thus the structure of a network database is extremely complicated because of these many-to-many relationships in which one record can be used as a key of the entire database. A network database is structured in the form of a graph that is also a data structure.

Advantages: 1. Speed of access is faster because of the predefined data paths. 2. Provide very efficient "High-speed" retrieval.3. Ability to handle more relationship types. The network model can handle the one-to-many and many-to-

many relationships. 4. Simplicity

The network model is conceptually simple and easy to design. 5. Data Integrity

In a network model, no member can exist without an owner. A user must therefore first define the owner record and then the member record. This ensures the integrity.

6. Ease of data accessIn the network database terminology, a relationship is a set. Each set comprises of two types of records.an owner record and a member record, In a network model an application can access an owner record and all the member records within a set.

7. Data IndependenceThe network model draws a clear line of demarcation between programs and the complex physical storage details. The application programs work independently of the data. Any changes made in the data characteristics do not affect the application program.

Disadvantages 1. System complexity.

In a network model, data are accessed one record at a time. This males it essential for the database designers, administrators, and programmers to be familiar with the internal data structures to gain access to the data. Therefore, a user friendly database management system cannot be created using the network model.

2. Lack of Structural independence.Making structural modifications to the database is very difficult in the network database model 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. Though the network model achieves data independence, it still fails to achieve structural independence.

3. Procedural access language.

o Relational Model The Relational Model was the first theoretically founded and well thought out Data Model, proposed by EfCodd in 1970, then a researcher at IBM. It has been the foundation of most database software and theoretical database research ever since. The Relational Model is a depiction of how each piece of stored information relates to the other stored information. It shows how tables are linked, what type of links are

between tables, what keys are used, what information is referenced between tables. It's an essential part of developing a normalized database structure to prevent repeat and redundant data storage. The basic idea behind the relational model is that a database consists of a series of unordered tables (or relations) that can be manipulated using non-procedural operations that return tables. This model was in vast contrast to the more traditional database theories of the time that were much more complicated, less flexible and dependent on the physical storage methods of the data. The RELATIONAL database model is based on the Relational Algebra, set theory and predicate logic.

The relational data model provides several advantages, but the main advantages are; 1. It allows for developing simple but powerful structure for databases. 2. It allows separation of the logical and physical level, so that logical design can be performed without

considering the storage structures. 3. It allows for designing or expressing the data of an organization in a simple way, which can easily be

understood. 4. The data operations can easily be expressed in a simple way. 5. It allows for applying data integrity rules on the relations of database. 6. Data from multiple tables can be retrieved very easily. 7. It allows users for inserting, modifying, and deleting the rows in a table without facing any problems.

Disadvantages:1. Performance:

A major constraint and therefore disadvantage in the use of relational database system is machine performance. If the number of tables between which relationships to be established are large and the tables themselves effect the performance in responding to the sql queries.

2. Physical Storage Consumption:With an interactive system, for example an operation like join would depend upon the physical storage also. It is, therefore common in relational databases to tune the databases and in such a case the physical data layout would be chosen so as to give good performance in the most frequently run operations. It therefore would naturally result in the fact that the lays frequently run operations would tend to become even more shared.

4. Slow extraction of meaning from data: If the data is naturally organized in a hierarchical manner and stored as such, the hierarchical approach may give quick meaning for that data

o The Entity-Relationship Model The entity-relationship (E-R) data model is based on a concept of a real world that consists of a collection of basic objects, called entities, and of relationships among these objects. An entity is a “thing” or “object” in the real world that is distinguishable from other objects. For example, each student is an entity, and book can be considered as entities. Entities are described in a database by a set of attributes. For example, the attributes book name and author may describe one particular book in a library, and they form attributes of the book entity set. Similarly, attributes student-name, student address and gender may describe a student entity. An extra attribute student_id is used to uniquely identify student. A unique student identifier must be assigned to each student. A relationship is an association among several entities. For example, a marks relationship associates a student with each student that they have. The set of all entities of the same type and the set of all relationships of the same type are termed an entity set and relationship set, respectively. 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

Fig E-R diagram corresponding to customers and loans

ER Diagrams UsageWhile able to describe just about any system, ER diagrams are most often associated with complex databases that are used in software engineering and IT networks. In particular, ER diagrams are frequently used during the design stage of a development process in order to identify different system elements and their relationships with each other. For example, inventory software used in a retail shop will have a database that monitors elements such as purchases, item, item type, and item source and item price.

Advantages Disadvantages Conceptual simplicity Visual representation Effective communication Integration with the relational database model

Limited constraint representation Limited relationship representation No representation of data manipulation Loss of information

DatabaseLanguageso DDL (data definition language)

For describing data and data structures a suitable description tool, a data definition language (DDL), is needed. With this help a data scheme can be defined and also changed later. Typical DDL operations (with their respective keywords in the structured query language SQL: Creation of tables and definition of attributes (CREATE TABLE ...) Change of tables by adding or deleting attributes (ALTER TABLE …) Deletion of whole table including content (DROP TABLE …)

o DML (data manipulation language) Additionally a language for the descriptions of the operations with data like store, search, read, change, etc. the so-called data manipulation, is needed. Such operations can be done with a data manipulation language (DML). Within such languages keywords like insert, modify, update, delete, select, etc. are common. Typical DML operations (with their respective keywords in the structured queryLanguage SQL: Add data (INSERT) Change data (UPDATE) Delete data (DELETE) Query data (SELECT)

o DCl (Data control language): it provides utilities to privilege like grant, revoke.o TCL (Transaction control language) it provide utility for transaction management like commit, rolback.

An object-oriented database management system (OODBMS)An object-oriented database management system (OODBMS), sometimes shortened to ODBMS for object database management system), is a database management system (DBMS) that supports the modeling and creation of data as objects. This includes some kind of support for classes of objects and the inheritance of class properties and methods by subclasses and their objects. There is currently no widely agreed-upon standard for what constitutes an OODBMS, and OODBMS products are considered to be still in their infancy. In the meantime, the object-relational database management system (ORDBMS), the idea that object-oriented database concepts can be superimposed on relational databases, is more commonly encountered in available products. An object-oriented database interface standard is being developed by an industry group, the Object Data Management Group (ODMG). The Object Management Group (OMG) has already standardized an object-oriented data brokering interface between systems in a network.

A core object-oriented data model consists of the following basic object-oriented concepts: (1) Object and object identifier: Any real world entity is uniformly modeled as an object (associated with a unique id: used to pinpoint an object to retrieve). (2) Attributes and methods: every object has a state (the set of values for the attributes of the object) and a behavior (the set of methods - program code - which operate on the state of the object). The state and behavior encapsulated in an object are accessed or invoked from outside the object only through explicit message passing. An attribute is an instance variable, whose domain may be any class: user-defined or primitive. A class composition hierarchy (aggregation relationship) is orthogonal to the concept of a class hierarchy. The link in a class composition hierarchy may form cycles. (3) Class: a means of grouping all the objects which share the same set of attributes and methods. An object must belong to only one class as an instance of that class (instance-of relationship). A class is similar to an abstract data type. A class may also be primitive (no attributes), e.g., integer, string, Boolean. (4) Class hierarchy and inheritance: derive a new class (subclass) from an existing class (superclass). The subclass inherits all the attributes and methods of the existing class and may have additional attributes and methods. single inheritance (class hierarchy) vs. multiple inheritance (class lattice).

Object Database Advantages over RDBMS o Objects don't require assembly and disassembly saving coding time and execution time to assemble or

disassemble objects. o Reduced paging o Easier navigation o Better concurrency control - A hierarchy of objects may be locked. o Data model is based on the real world. o Works well for distributed architectures. o Less code required when applications are object oriented. o Reduced Maintenance o Improved Reliability and Flexibility o High Code Reusability

Object Database Disadvantages compared to RDBMS o Lower efficiency when data is simple and relationships are simple. o Relational tables are simpler. o Late binding may slow access speed. o More user tools exist for RDBMS. o Standards for RDBMS are more stable. o Support for RDBMS is more certain and change is less likely to be required.

Fig. different between OODMS v/s RDMSTransaction   A transaction is a logical unit of work that contains one or more SQL statements. A transaction is an atomic unit. The effects of all the SQL statements in a transaction can be either all  committed (applied to the database) or all rolled back (undone from the database).A transaction begins with the first executable SQL statement. A transaction ends when it is committed or rolled back, either explicitly with a COMMIT or ROLLBACK statement or implicitly when a DDL statement is issued.

To illustrate the concept of a transaction, consider a banking database. When a bank customer transfers money from a savings account to a checking account, the transaction can consist of three separate operations:

1. Decrement the savings account2. Increment the checking account3. Record the transaction in the transaction journal

ACID Properties1. Atomicity

Either all operations of a transaction are reflected in the database or none of them (all or nothing)2. Consistency

If the database was is a consistent state before the transaction started, it will be in a consistent state after the transaction has been executed

3. IsolationIf transactions are executed in parallel, the effects of an ongoing transaction must not be visible to other transactions

4. DurabilityAfter a transaction finished successfully, its changes are persistent and will not be lost (e.g. on system failure)

Transaction States1. Active.

Initial state; transaction is in this state while executing2. Partially committed.

After the last statement has been executed.3. Committed.

After successful completion.4. Failed.

After discovery that a normal execution is no longer possible. logical error (e.g. bad input), system error (e.g. deadlock) or system crash

5. Aborted: after the rollback of a transaction

Database System structure.

Query processor: This is a major DBMS component that transforms queries into a series of low-level instructions directed to the database manager. Database manager (DM): The DM interfaces with user-submitted application programs and queries. The DM accepts queries and examines the external and conceptual schemas to determine what conceptual records are required to satisfy the request. The DM then places a call to the file manager to perform the request. The components of the DM.File manager: The file manager manipulates the underlying storage files and manages the allocation of storage space on disk. It establishes and maintains the list of structures and indexes defined in the internal schema. DML preprocessor: This module converts DML statements embedded in an application program into standard function calls in the host language. The DML preprocessor must interact with the query processor to generate the appropriate code.DDL compiler: The DDL compiler converts DDL statements into a set of tables containing metadata. These tables are then stored in the system catalog while control information is stored in data file headers. Catalog manager: The catalog manager manages access to and maintains the system catalog. The system catalog is accessed by most DBMS components.

The major software components for the database manager are as follows:Authorization control This module checks that the user has the necessary authorization to carry out the required operation.Command processor Once the system has checked that the user has authority to carry out the operation; control is passed to the command processor.Integrity checker For an operation that changes the database, the integrity checker checks that the requested operation satisfies all necessary integrity constraints (such as key constraints).Query optimizer This module determines an optimal strategy for the query execution.Transaction manager This module performs the required processing of operations it receives from transactions.Scheduler This module is responsible for ensuring that concurrent operations on the database proceed without conflicting with one another. It controls the relative order in which transaction operations are executed.

Recovery manager This module ensures that the database remains in a consistent state in the presence of failures. It is responsible for transaction commit and abort.Buffer manager This module is responsible for the transfer of data between main memory and secondary storage, such as disk and tape. The recovery manager and the buffer manager are sometimes referred to collectively as the data manager. The buffer manager is sometimes known as the cache manager.

Application architecturesThe client takes the user’s request, checks the syntax and generates database requests in SQL or another database language appropriate to the application logic. It then transmits the message to the server, waits for a response, and formats the response for the end-user. The server accepts and processes the database requests, then transmits the results back to the client. The processing involves checking authorization, ensuring integrity, maintaining the system catalog, and performing query and update processing. In addition, it also provides concurrency and recovery control.

Two-tier client–server architecture.

There are many advantages to this type of architecture. For example:1. It enables wider access to existing databases.2. Increased performance – if the clients and server reside on different computers then different CPUs

can be processing applications in parallel. It should also be easier to tune the server machine if its only task is to perform database processing.

3. Hardware costs may be reduced – it is only the server that requires storage and processing power sufficient to store and manage the database.

4. Communication costs are reduced – applications carry out part of the operations on the client and send only requests for database access across the network, resulting in less data being sent across the network.

5. Increased consistency – the server can handle integrity checks, so that constraints need be defined and validated only in the one place, rather than having each application program perform its own checking.

6. It maps on to open systems architecture quite naturally.

Three-Tier Client–Server Architecture

Three-Tier Client–Server Architecture includes:1. The user interface layer, which runs on the end-user’s computer (the client). 2. The business logic and data processing layer. This middle tier runs on a server and is often called the

application server.

3. A DBMS, which stores the data required by the middle tier. This tier may run on a separate server called the database server.

Advantages:1. The need for less expensive hardware because the client is ‘thin’.2. Application maintenance is centralized with the transfer of the business logic for many end-users into a

single application server. This eliminates the concerns of software distribution that are problematic in the traditional two-tier client–server model.

3. The added modularity makes it easier to modify or replace one tier without affecting the other tiers. 4. Load balancing is easier with the separation of the core business logic from the database functions.

An additional advantage is that the three-tier architecture maps quite naturally to the Web environment, with a Web browser acting as the ‘thin’ client, and a Web server acting as the application server. The three-tier architecture can be extended to n-tiers, with additional tiers added to provide more flexibility and scalability. For example, the middle tier of the three-tier architecture could be split into two, with one tier for the Web server and another for the application server.

Database users and administratorsA 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.There are four different types of database-system users, differentiated by the way they expect to interact with the system. Different types of user interfaces have been designed for the different types of users.1. Naive users are unsophisticated users who interact with the system by invoking one of the application

programs that have been written previously. For example consider a user who wishes to find his account balance over the World Wide Web. Such a user may access a form, where she enters her account number. An application program at the Web server then retrieves the account balance, using the given account number, and passes this information back to the user

2. Application programmers are computer professionals who write application programs. Application programmers can choose from many tools to develop user interfaces. Rapid application development (RAD) like visual basic or DOT NET, are tools that enable an application programmer to construct forms and reports without writing a program.

3. Specialized 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-modeling systems.

4. Database Administrator is a person who has central control over both data and application programs. The responsibilities of DBA vary depending upon the job description and corporate and organization policies. Some of the responsibilities of DBA are given here. Schema definition and modification: The overall structure of the database is known as database schema. It is the responsibility of the DBA to create the database schema by executing a set of data definition statements in DDL. The DBA also carries out the changes to the schema according to the changing needs of the organization. New software installation: It is the responsibility of the DBA to install new DBMS software, application software, and other related software. After installation, the DBA must test the new software. Security enforcement and administration: DBA is responsible for establishing and monitoring the security of the database system. It involves adding and removing users, auditing, and checking for security problems. Data analysis: DBA is responsible for analyzing the data stored in the database, and studying its performance and efficiency in order to effectively use indexes, parallel query execution, etc. Preliminary database design: The DBA works along with the development team during the database design stage due to which many potential problems that can arise later (after installation) can be avoided. Physical organization modification: The DBA is responsible for carrying out the modifications in the physical organization of the database for better performance.Routine maintenance checks: The DBA is responsible for taking the database backup periodically in order to Recover from any hardware or software failure (if occurs). Other routine maintenance checks that are carried out by the DBA are checking data storage and ensuring the availability of free disk space for normal operations, upgrading disk space as and when required, etc.