DATABASE MANAGEMENT SYSTEM

UNIT-1

DATABASE
Defined as collection of inter-related relevant data stored together to serve multiple applications Data is stored so that it is independent of the programs using it A controlled approach is used to add new data, to retrieve and modify existing data within the database

What is a Database Management System? A DBMS is a collection of programs which provide management of databases control access to data contain a query information easily language to retrieve

Database Design It is important to design the database in such a way that: A specific item can be reached easily
(maximum guarantee that the desired record will be reached)

The database can respond to the user s different questions easily

(necessary relationships are provided)

The database space

occupies

minimum

storage

(choosing data types and how to express a certain concept is important)

The database contains no unnecessary data

(storing the gross salary is enough, the net salary can be calculated from the gross salary)

Data can be added and updated easily without causing mistakes

(no data redundancy)

Data redundancy Different and conflicting versions of the same data e.g. Employee database:
personal info - ID - name - address payroll - ID (relating parameter) - name (causes redundancy) - gross salary

STEPS IN DATABASE DESIGN

Requirement analysis
What does the user want?

Conceptual database design

Defining the entities and attributes, and the relationships between these --> The ER model

Physical database design

Implementation of the conceptual design using a Database Management System

TERMINOLOGY
Entity --> What is this table about? students Attribute (Field) --> What items of information are necessary to keep concerning this entity?
ID, name, department, year, advisor

Record (Tuple) --> A set of values for each attribute for one item
20027654 Anitha MBA 2 Mr.X

Key --> The attribute used to define a required item

who is the advisor of Anitha? Types of keys:
* Primary Key: Key used to uniquely identify a record * Foreign Key: A field in this table which is the Primary key of another table

Relationship --> Definitions linking two or more tables

Characteristics of DBMS
Self-describing nature of a database system: A DBMS catalog stores the description of the database. The description is called meta-data. This allows the DBMS software to work with different databases. Insulation between programs and data: Called program-data independence. Allows changing data storage structures and operations without having to change the DBMS access programs.

Slide 1-10

 Data Abstraction: A data model is used to hide storage details and present the users with a conceptual view of the database. Support of multiple views of the data: Each user may see a different view of the database, which describes only the data of interest to that user. Sharing of data and multiuser transaction processing : allowing a set of concurrent users to retrieve and to update the database. Concurrency control within the DBMS guarantees that each transaction is correctly executed or completely aborted. OLTP (Online Transaction Processing) is a major part of database applications.

Database users
Users may be divided into those who actually use and control the content
(called Actors on the Scene )

and those who enable the database to be developed and the DBMS software to be designed and implemented
(called Workers Behind the Scene ).

Actors on the scene

Database administrators: responsible for authorizing access to the database, for coordinating and monitoring its use, acquiring software, and hardware resources, controlling its use and monitoring efficiency of operations. Database Designers: responsible to define the content, the structure, the constraints, and functions or transactions against the database. They must communicate with the end-users and understand their needs. End-users: they use the data for queries, reports and some of them actually update the database content.

Categories of End-users
Casual : access database occasionally when needed Nave or Parametric : they make up a large section of the end-user population. They use previously well-defined functions in the form of canned transactions against the database. Examples are bank-tellers or reservation clerks who do this activity for an entire shift of operations.

 Sophisticated : these include business analysts, scientists, engineers, others thoroughly familiar with the system capabilities. Many use tools in the form of software packages that work closely with the stored database. Stand-alone : mostly maintain personal databases using ready-to-use packaged applications. An example is a tax program user that creates his or her own internal database.

Advantages of Using the Database Approach

Controlling redundancy in data storage and in development and maintenance efforts. Sharing of data among multiple users. Restricting unauthorized access to data. Providing persistent storage for program Objects Providing Storage Structures for efficient Query Processing

 Providing backup and recovery services. Providing multiple interfaces to different classes of users. Representing complex relationships among data. Drawing Inferences and Actions using rules Potential for enforcing standards: this is very crucial for the success of database applications in large organizations Standards refer to data item names, display formats, screens, report structures, meta-data (description of data) etc.

 Reduced application development time: incremental time to add each new application is reduced. Flexibility to change data structures: database structure may evolve as new requirements are defined. Availability of up-to-date information very important for on-line transaction systems such as airline, hotel, car reservations. Economies of scale: by consolidating data and applications across departments wasteful overlap of resources and personnel can be avoided.

When not to use a DBMS

Main inhibitors (costs) of using a DBMS:
High initial investment and possible need for additional hardware. Overhead for providing generality, security, concurrency control, recovery, and integrity functions.

When a DBMS may be unnecessary:

If the database and applications are simple, well defined, and not expected to change. If there are stringent real-time requirements that may not be met because of DBMS overhead. If access to data by multiple users is not required.

 When no DBMS may suffice:

If the database system is not able to handle the complexity of data because of modeling limitations If the database users need special operations not supported by the DBMS.

Data Models
Physical or logical structure of a database is given by a data model Collection of conceptual tools used for describing data, data relationships, data semantics and data constraints A set of concepts to describe the structure of a database, the operations for manipulating these structures, and certain constraints that the database should obey. Evolution of different models is still in progress Classified into three categories

 Object-based data models:

used in describing data and data relationships in accordance with concept Gains wide acceptance because of flexible structuring capabilities Entity-Relationship model is widely used in practice as an appropriate database design tool

 Record based data models:

Used to specify the overall logical structure of the database Widely accepted models are relational model, network model and hierarchical model

 Physical Data Model:

Used to have higher level description of the storage structure of the database Possible to implement the database at the system level A very few models are proposed so far Unifying model and frame memory model

Instances and Schemas

Similar to types and variables in programming languages Schema the logical structure of the database xample: 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

Instances and Schemas

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.

Example of a Database Schema

Files vs. DBMS

Application must stage large datasets between main memory and secondary storage (e.g., buffering, page-oriented access, 32-bit addressing, etc.) Special code for different queries Must protect data from inconsistency due to multiple concurrent users Crash recovery Security and access control

Database Architecture
An architecture for a database system

Application Architectures

Two-tier architecture: E.g. client programs using ODBC/JDBCto communicate with a database Three-tier architecture: E.g. web-based applications, and applications built using middleware

Three-Schema Architecture
Proposed to support DBMS characteristics of:
Program-data independence. Support of multiple views of the data.

Not explicitly used in commercial DBMS products, but has been useful in explaining database system organization

Three-Schema Architecture
Defines DBMS schemas at three levels:
Internal schema at the internal level to describe physical storage structures and access paths (e.g indexes).
Typically uses a physical data model.

Conceptual schema at the conceptual level to describe the structure and constraints for the whole database for a community of users.
Uses a conceptual or an implementation data model.

External schemas at the external level to describe the various user views.
Usually uses the same data model as the conceptual schema.

The three-schema architecture

Three-Schema Architecture
Mappings among schema levels are needed to transform requests and data.
Programs refer to an external schema, and are mapped by the DBMS to the internal schema for execution. Data extracted from the internal DBMS level is reformatted to match the user s external view (e.g. formatting the results of an SQL query for display in a Web page)

Data Independence
Logical Data Independence:
The capacity to change the conceptual schema without having to change the external schemas and their associated application programs.

Physical Data Independence:

The capacity to change the internal schema without having to change the conceptual schema. For example, the internal schema may be changed when certain file structures are reorganized or new indexes are created to improve database performance

Data Independence (continued)

When a schema at a lower level is changed, only the mappings between this schema and higher-level schemas need to be changed in a DBMS that fully supports data independence. The higher-level schemas themselves are unchanged.
Hence, the application programs need not be changed since they refer to the external schemas.

Classification of DBMSs
Based on the data model used
Traditional: Relational, Network, Hierarchical. Emerging: Object-oriented, Object-relational.

Other classifications
Single-user (typically used with personal computers)vs. multi-user (most DBMSs). Centralized (uses a single computer with one database) vs. distributed (uses multiple computers, multiple databases)

Figure 1-5 Components of the Database Environment

Components of the Database Environment

CASE Tools computer-aided software engineering computer Repository centralized storehouse of metadata Database Management System (DBMS) software for managing the database Database storehouse of the data Application Programs software using the data User Interface text and graphical displays to users Data/Database Administrators personnel responsible for maintaining the database System Developers personnel responsible for designing databases and software End Users people who use the applications and databases

E-R Model-Definitions
Entity- An entity is a thing which can be easily identified. Attribute- An attribute is a property of a given entity. Relationship- A relationship is an association among entities.

Symbols Used in ER Diagrams

Symbols Contd .

A basic ER diagram
A B C

X,Y are two entities. A,B,C are three attributes. The entity X contains one attribute A and the entity Y contains two attributes B and C. The entities X and Y are related through a relationship Z.

Entity
Entity Type- An entity type is a set Regular Entity of things that shares common properties.(Entity type is usually written in uppercase) Entity Instance- An entity instance is Weak Entity a specific individual thing. Dependant/Weak Entity- An entity whose existence depends upon the existence of another entity. Independent/Regular Entity- An A weak entity is represented by a double lined box. The above entity that does not depend upon schematic represents the existence of the weak entity on a any other entity for existence. regular entity.

A complex ER diagram
A B

Example

Degree of a Relationship
The number of participating entities in a relationship. The entities involved in a particular relationship are referred to as participants. The number of participants in a relationship is called the degree.

Recursive (Unary) Relationship

A relationship where the same entity participates more than once in different roles.
Supervision

Supervisor

Supervisee

Employee

Binary Relationship
In a binary relationship, two entities are connected.

Employee

Works For

Department

Ternary Relationships
A ternary relationship involves three entities and is used when a binary relationship is inadequate.
Supplier Supply Project

Parts

Example
A library database is used to store information about books, publishers and members of the library. The database keeps track of the following data.
Book: Book ID, Title Member: Member Card No, Name, Address, Phone No Publisher: Publisher Name (Unique), Address (The publisher may have several office branches), Phone No

Consider the following relationship.

The library books are borrowed by the members. The books are published by the publishers.

Book ID

Title

Phone No Member Card No

Book

Burrow

Member City

Publish

Phone No

Name

Address

Publisher

House No

FName

LName

House No

Publisher Name

Address

City Street

 A relationship usually has certain constraints that limits the possible combinations of entities that may participate in relationship instances. There are two types of relationship constraints.
Cardinality Ratio Participation

The cardinality ratio specifies the number of relationship instances that an entity can participate.

Mapping Constraints
ssn

since name lot did dname budget

Employees

Manages

Departments

1-to-1

1-to Many

Many-to-1

Many-to-Many

8/7/2008

58

 Common cardinality ratios for binary relationships are:

i. One to One (1:1) ii. One to Many (1:M) iii. Many to Many (M:M)

One to One Relationship

An entity in A is associated with at most one entity in B, and an entity in B is associated with at most one entity in A.

 Eg: A Department entity to the Employee who manages that department.

1:1

Employee

Manages

Department

 One to Many Relationship

An entity in A is associated with any number (zero or more) of entities in B. An entity in B, however, can be associated with at most one entity in A. Eg: One Employee can work only in one department but many employees can work in a department.
1: M

Employee

Works In

Department

 Many to Many Relationship

An entity in A is associated with any number (zero or more) of entities in B, and an entity in B is associated with any number (zero or more) of entities in A.
Eg: If an Employee can work in several Projects and several Employees work on a Project, then the cardinality ratio is M:M.

M:M

Weak Entities
we assumed that an entity set always has a key, but this is not true An entity set is called a weak entity if its existence depends on other entities called strong entities A weak entity does not have sufficient attributes to form a primary key Example: employees can purchase insurance policies to cover their dependents. To record information about policy including who is covered by each policy. In this case if an employee quits, any policy owned by him/her is terminated and we want to delete all the relevant policy and dependent information from the database
8/7/2008 63

Weak Entities
A weak entity can be identified uniquely only by considering the primary key of another (owner) entity. Owner entity set and weak entity set must participate in a one-to-many relationship set (one owner, many weak entities). Weak entity set must have total participation in this identifying relationship set. pname is a partial key of weak entity set
name ssn lot cost pname age

Employees
8/7/2008

Policy

Dependents
64