Evolution of Database Management systems

Mahindra Satyam Learning World

Mahindra Satyam 2009

The Traditional Approach To Data Management

Create new files for each application

Data redundancy
Data integrity

Mahindra Satyam 2009 2

Disadvantages of File Processing

Program-Data Dependence - All programs maintain metadata for each file they use Data Redundancy (Duplication of data) - Different systems/programs have separate copies of the same data Limited Data Sharing - No centralized control of data Lengthy Development Times - Programmers must design their own file formats Excessive Program Maintenance - 80% of information systems budget

Mahindra Satyam 2009 3

Components of DBMS

Mahindra Satyam 2009 4

Application architectures

Two-tier architecture: E.g. client programs using ODBC/JDBC to communicate with a database Three-tier architecture: E.g. web-based applications, and applications built using middleware
Mahindra Satyam 2009 5

Levels of Abstraction

Physical level: describes how a record (e.g., customer) is stored. Logical level: describes data stored in database, and the relationships among the data. type customer = record customer_id : string; customer_name : string; customer_street : string; customer_city : integer; end;

View level: application programs hide details of data types. Views can also hide information (such as an employees salary) for security purposes.

Mahindra Satyam 2009 6

View of Data

Mahindra Satyam 2009 7

Instances and Schemas

Similar to types and variables in programming languages Schema the logical structure of the database Example: The database consists of information about a set of customers and accounts and the relationship between them) Analogous to type information of a variable in a program Physical schema: database design at the physical level Logical schema: database design at the logical level Instance the actual content of the database at a particular point in time Analogous to the value of a variable

Physical Data Independence the ability to modify the physical schema without changing the logical schema Applications depend on the logical schema In general, the interfaces between the various levels and components should be well defined so that changes in some parts do not seriously influence others.
Mahindra Satyam 2009 8

Database Models
Definition: collection of logical constructs used to represent data structure and relationships within the database

Conceptual models: logical nature of data representation; if emphasizes on

what entity is presented; it is used for database design as blueprint Implementation models: emphasis on how the data are represented in the database

Mahindra Satyam 2009 9

Database Models
Conceptual models include Entity-relationship database model (ERDBM) Object-oriented database model (OODBM) Implementation models include Hierarchical database model (HDBM) Network database model (NDBM) Relational database model (RDBM) Object-oriented database model (OODBM)

Mahindra Satyam 2009 10

Hierarchical Database

Logically represented by an upside down tree Each parent can have many children (segment linkage) Each child has only one parent

Mahindra Satyam 2009 11

Hierarchical Database Model: Advantages

Conceptual simplicity: relationship between layers is logically simple; design process is simple Database security: enforced uniformly through the system Data integrity Data independence Efficiency in 1:M relationships and when uses require large numbers of transactions Dominant in 1970s , when we used mainframe system with large databases

Mahindra Satyam 2009 12

Hierarchical Database Model

Disadvantages

Complex implementation: physical data storage characteristics; database

design is complicated Difficult to manage and lack of standards Lacks structural independence Applications programming and use complexity (pointer based) Implementation limitations, i.e. especially it only handle 1:M type of model

Mahindra Satyam 2009 13

Network database Model

Hierarchical like node arrangement Child node can have more than 1 parent

Many-to-many relationships
Access via multiple pathways Flexible, powerful

Mahindra Satyam 2009 14

Network Database Model

Advantages Conceptual simplicity, just lime HDM Handles more relationship types (but all 1:M relationship) Data access flexibility Promotes database integrity Data independence Conformance to standards Disadvantages System complexity Lack of structural independence

Mahindra Satyam 2009 15

The Relational Model

Was introduced in 1970 by Dr. E. F. Codd (of IBM)

Commercial relational databases began to appear in the 1980s

Today relational databases have become the dominant technology for database management

Mahindra Satyam 2009 16

Relational Database

Data stored in tables

Rows and columns

Record = row Field = column

Most flexible Tables related via common data item Easy to use

Mahindra Satyam 2009 17

Relational Database Model: Advantages

Structural independence: data access path is irrelevant to database design;

change structure will not affect the database

Improved conceptual simplicity Easier database design, implementation, management, and use Ad hoc query capability with SQL (4GL is added) Powerful database management system

Mahindra Satyam 2009 18

Relational Database Model: Disadvantages

Substantial hardware and system software overhead

Poor design and implementation is made easy

May promote islands of information problems

Mahindra Satyam 2009 19

Relational Database Model

Mahindra Satyam 2009 20

Object-Oriented Database

Uses an object-oriented data model

Can store instructions

Handles unstructured data

Photographs, audio, video

Data is organized using

Objects Classes Entities

Attributes
Methods

Mahindra Satyam 2009 21

Thank You

mahindrasatyam.net
Safe Harbor This document contains forward-looking statements within the meaning of section 27A of Securities Act of 1933, as amended, and section 21E of the Securities Exchange Act of 1934, as amended. The forward-looking statements contained herein are subject to certain risks and uncertainties that could cause actual results to differ materially from those reflected in the forward-looking statements. Satyam undertakes no duty to update any forward-looking statements. For a discussion of the risks associated with our business, please see the discussions under the heading Risk Factors in our report on Form 6-K concerning the quarter ended September 30, 2008, furnished to the Securities and Exchange Commission on 07 November, 2008, and the other reports filed with the Securities and Exchange Commission from time to time. These filings are available at http://www.sec.gov

Mahindra Satyam 2009 22