Unit–I:

Database System Applications

A Historical Perspective: Data is a collection of facts and figures. Charles

Bachman was the first person to develop the Integrated Data Store which was
based on network data model.

In the late 1960’s, IBM developed the Integrated Management Systems which
is the standard database system used till date in many places.

It was developed based on the hierarchical database model. It was during the
year 1970 that the relational database model was developed by Edgar Codd.

Many of the database models we use today are relational based.

*****************************************************************
Main characteristics of the database approach and how it differs from
traditional file system:

In a traditional file processing system, each user defines and implements its own
modifications to the files needed for a selected software application as a part of
programming the appliance. In the database approach, one repository maintains
data which is defined once then accessed by various users in that database.

File Systems versus a DBMS

Differences between DBMS and File system or

Differences between Traditional File System and Data Base

DBMS File System

DBMS is a collection of data. In File system is a collection of data. In this system,

DBMS, the user is not required to the user has to write the procedures for managing
write the procedures. the database.

DBMS gives an abstract view of File system provides the detail of the data
data that hides the details. representation and storage of data.

DBMS provides a crash recovery File system doesn't have a crash mechanism, i.e.,
mechanism, i.e., DBMS protects the if the system crashes while entering some data,
user from the system failure. then the content of the file will lost.

DBMS provides a good protection It is very difficult to protect a file under the file
mechanism. system.

DBMS contains a wide variety of File system can't efficiently store and retrieve the
sophisticated techniques to store data.
and retrieve the data.

DBMS takes care of Concurrent In the File system, concurrent access has many
access of data using some form of problems like redirecting the file while other
locking. deleting some information or updating some
information.

****************************************************************

The DataModel: Data Model is the modeling of the data description, data
semantics, and consistency constraints of the data. It provides the conceptual tools
for describing the design of a database at each level of data abstraction.
Therefore, there are following four data models used for understanding the
structure of the database:
1) Relational Data Model: This type of model designs the data in the form of
rows and columns within a table. Thus, a relational model uses tables for
representing data and in-between relationships. Tables are also called relations.
This model was initially described by Edgar F. Codd, in 1969. The relational data
model is the widely used model which is primarily used by commercial data
processing applications.

2) Entity-Relationship Data Model: An ER model is the logical representation of

data as objects and relationships among them. These objects are known as entities,
and relationship is an association among these entities. This model was designed
by Peter Chen and published in 1976 papers. It was widely used in database
designing. A set of attributes describe the entities. For example, student_name,
student_id describes the 'student' entity. A set of the same type of entities is known
as an 'Entity set', and the set of the same type of relationships is known as
'relationship set'.

3) Object-based Data Model: An extension of the ER model with notions of

functions, encapsulation, and object identity, as well. This model supports a rich
type system that includes structured and collection types. Thus, in 1980s, various
database systems following the object-oriented approach were developed. Here, the
objects are nothing but the data carrying its properties.

4) Semi structured Data Model: This type of data model is different from the
other three data models. The semi structured data model allows the data
specifications at places where the individual data items of the same type may have
different attributes sets. The Extensible Markup Language, also known as XML, is
widely used for representing the semi structured data. Although XML was initially
designed for including the markup information to the text document, it gains
importance because of its application in the exchange of data.

******************************************************************

Levels of Abstraction in a DBMS: Database systems comprise of complex data

structures. Thus, to make the system efficient for retrieval of data and reduce
the complexity of the users, developers use the method of Data Abstraction.

There are mainly three levels of data abstraction:

1. Internal Level: Actual PHYSICAL storage structure and access paths.

2. Conceptual or Logical Level: Structure and constraints for the entire
database.
3. External or View level: Describes various user views.

Internal Scheme: The internal schema defines the physical storage structure of the
database. The internal schema is a very low-level representation of the entire
database. It contains multiple occurrences of multiple types of internal record.

About Internal schema:

 The internal schema is the lowest level of data abstraction

 It helps you to keeps information about the actual representation of the entire
database. Like the actual storage of the data on the disk in the form of
records
 The internal view tells us what data is stored in the database and how
  It never deals with the physical devices. Instead, internal schema views a
physical device as a collection of physical pages

Conceptual Schema/Level
The conceptual schema describes the Database structure of the whole database for
the community of users. This schema hides information about the physical
storage structures and focuses on describing data types, entities, relationships,
etc.

This logical level comes between the user level and physical storage view.
However, there is only single conceptual view of a single database.

Facts about Conceptual schema:

 Defines all database entities, their attributes, and their relationships

 Security and integrity information
 In the conceptual level, the data available to a user must be contained in or
derivable from the physical level

External Schema/Level
An external schema describes the part of the database which specific user is
interested in. It hides the unrelated details of the database from the user. There
may be “n” number of external views for each database.

Each external view is defined using an external schema, which consists of

definitions of various types of external record of that specific view.

An external view is just the content of the database as it is seen by some specific
particular user. For example, a user from the sales department will see only
sales related data.

Facts about external schema:

 An external level is only related to the data which is viewed by specific end
users.
 This level includes some external schemas.
 External schema level is nearest to the user
Data Independence: Data independence can be explained using the three-schema
architecture.

o Data independence refers characteristic of being able to modify the

schema at one level of the database system without changing(altering)
the schema at the next higher level.

There are two types of data independence:

1. Logical Data Independence

 o Logical data independence refers characteristic of being able to change the
conceptual schema without having to change the external schema.
o Logical data independence is used to separate the external level from the
conceptual view.
o If we do any changes in the conceptual view of the data, then the user view
of the data would not be affected.
o Logical data independence occurs at the user interface level.

2. Physical Data Independence

o Physical data independence can be defined as the capacity to change the

internal schema without having to change the conceptual schema.
o If we do any changes in the storage size of the database system server, then
the Conceptual structure of the database will not be affected.
o Physical data independence is used to separate conceptual levels from the
internal levels.
o Physical data independence occurs at the logical interface level.
StructureofaDBMS: The database system is divided into three components:
Query Processor, Storage Manager, and Disk Storage.
1. Query Processor: 
It interprets the requests (queries) received from end user via an application
program into instructions. It also executes the user request which is received from
the DML compiler. 
Query Processor contains the following components – 
 
 DML Compiler – 
It processes the DML statements into low level instruction (machine
language), so that they can be executed. 
 
 DDL Interpreter – 
It processes the DDL statements into a set of table containing meta data (data
about data). 
 
 Embedded DML Pre-compiler – 
It processes DML statements embedded in an application program into
 procedural calls. 
 
 Query Optimizer – 
It executes the instruction generated by DML Compiler. 
 
2. Storage Manager: 
Storage Manager is a program that provides an interface between the data stored
in the database and the queries received. It is also known as Database Control
System. It maintains the consistency and integrity of the database by applying the
constraints and executes the DCL statements. It is responsible for updating,
storing, deleting, and retrieving data in the database. 
It contains the following components – 
 
 Authorization Manager – 
It ensures role-based access control, i.e,.Checks whether the particular person
is privileged to perform the requested operation or not. 
 
 Integrity Manager – 
It checks the integrity constraints when the database is modified. 
 
 Transaction Manager – 
It controls concurrent access by performing the operations in a scheduled way
that it receives the transaction. Thus, it ensures that the database remains in
the consistent state before and after the execution of a transaction. 
 
 File Manager – 
It manages the file space and the data structure used to represent information
in the database. 
 
 Buffer Manager – 
It is responsible for cache memory and the transfer of data between the
secondary storage and main memory. 
 
3. Disk Storage: 
It contains the following components – 
 
 Data Files – It stores the data. 
 
 Data Dictionary – It contains the information about the structure of any
database object. It is the repository of information that governs the metadata. 
 
 Indices – It provides faster retrieval of data item. 
*****************************************************************
Introduction to Database Design:

Database Design and ER Diagrams: Database design can be generally defined

as a collection of tasks or processes that enhance the designing, development,
implementation, and maintenance of enterprise data management system.
Designing a proper database reduces the maintenance cost thereby improving
data consistency and the cost-effective measures are greatly influenced in
terms of disk storage space. Therefore, there has to be a brilliant concept of
designing a database. The designer should follow the constraints and decide how
the elements correlate and what kind of data must be stored.
The main objectives behind database designing are to produce physical and
logical design models of the proposed database system.

Requirement Analysis

Planning - This stage is concerned with planning the entire DDLC (Database
Development Life Cycle). The strategic considerations are taken into account
before proceeding.

System definition - This stage covers the boundaries and scopes of the proper
database after planning.

Database Designing

Physical Model - The physical model is concerned with the practices and
implementations of the logical model.

Logical Model - This stage is primarily concerned with developing a model based
on the proposed requirements. The entire model is designed on paper without any
implementation or adopting DBMS considerations.
Implementation

Data conversion and loading - This section is used to import and convert data
from the old to the new system.

Testing - This stage is concerned with error identification in the newly

implemented system. Testing is a crucial step because it checks the database
directly and compares the requirement specifications.

o ER Diagram: ER model stands for an Entity-Relationship model. It is a

high-level data model. This model is used to define the data elements and
relationship for a specified system.
o It develops a conceptual design for the database. It also develops a very
simple and easy to design view of data.
o In ER modeling, the database structure is portrayed as a diagram called an
entity-relationship diagram.

For example, Suppose we design a school database. In this database, the student

will be an entity with attributes like address, name, id, age, etc. The address can be
another entity with attributes like city, street name, pin code, etc and there will be a
relationship between them.
There are three basic elements in an ER Diagram: entity, attribute, relationship.
There are more elements which are based on the main elements. They are weak
entity, multi valued attribute, derived attribute, weak relationship, and recursive
relationship.

Component of ER Diagram

Notation of ER diagram

Database can be represented using the notations. In ER diagram, many notations

are used to express the cardinality. Also known as ERDs or ER Models, they use
a defined set of symbols such as rectangles, diamonds, ovals and connecting lines
to depict the interconnectedness of entities, relationships and their attributes.

These notations are as follows:

Additional Features of the ER Model: It is a high-level data model. This model is
used to define the data elements and relationship for a specified system.
It develops a conceptual design for the database. It also develops a very simple
and easy to design view of data.

Basic constructs of ER modeling are entities, attributes, and relationships

Entity:

An entity can be a real-world object, either animate or inanimate, that can be

easily identifiable. For example, in a school database, students, teachers, classes,
and courses offered can be considered as entities. All these entities have some
attributes or properties that give them their identity.
An entity set is a collection of similar types of entities. An entity set may contain
entities with attribute sharing similar values. For example, a Students set may
contain all the students of a school; likewise a Teachers set may contain all the
teachers of a school from all faculties. Entity sets need not be disjoint.
******************************************************************

Attributes:
Entities are represented by means of their properties, called attributes. All
attributes have values. For example, a student entity may have name, class, and
age as attributes.
There exists a domain or range of values that can be assigned to attributes. For
example, a student's name cannot be a numeric value. It has to be alphabetic. A
student's age cannot be negative, etc.
Types of Attributes
 Simple attribute − Simple attributes are atomic values, which cannot be
divided further. For example, a student's phone number is an atomic value
of 10 digits.
 Composite attribute − Composite attributes are made of more than one
simple attribute. For example, a student's complete name may have
first_name and last_name.
 Derived attribute − Derived attributes are the attributes that do not exist in
the physical database, but their values are derived from other attributes
present in the database. For example, average_salary in a department should
not be saved directly in the database, instead it can be derived. For another
example, age can be derived from data_of_birth.
 Single-value attribute − Single-value attributes contain single value. For
example − Social_Security_Number.
 Multi-value attribute − Multi-value attributes may contain more than one
values. For example, a person can have more than one phone number,
email_address, etc.
These attribute types can come together in a way like −

 simple single-valued attributes

 simple multi-valued attributes
 composite single-valued attributes
 composite multi-valued attributes

******************************************************************
************
Entity-Set and Keys
Key is an attribute or collection of attributes that uniquely identifies an entity
among entity set.
For example, the roll_number of a student makes him/her identifiable among
students.
  Super Key − A set of attributes (one or more) that collectively identifies an
entity in an entity set.
 Candidate Key − A minimal super key is called a candidate key. An entity
set may have more than one candidate key.
 Primary Key − A primary key is one of the candidate keys chosen by the
database designer to uniquely identify the entity set.
******************************************************************
***********

Relationship and Relationship Sets

Relation: The association among entities is called a relationship. For example, an

employee works_at a department, a student enrolls in a course. Here, Works_at and
Enrolls are called relationships.

Relationship Set
A set of relationships of similar type is called a relationship set. Like entities, a
relationship too can have attributes. These attributes are called descriptive
attributes.
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
Mapping Cardinalities
Cardinality defines the number of entities in one entity set, which can be
associated with the number of entities of other set via relationship set.
 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-many − One entity from entity set A can be associated with more
than one entities of entity set B however an entity from entity set B, can be
associated with at most one entity.

 Many-to-one − More than one entities from entity set A can be associated
with at most one entity of entity set B, however an entity from entity set B
can be associated with more than one entity from entity set A.
  Many-to-many − One entity from A can be associated with more than one
entity from B and vice versa.

Draw an ER Diagram for BANK database schema with atleast five entity
types. Also specify Primary Key and Structural Constraints .

ER diagram is known as Entity-Relationship diagram. It is used to analyze to

structure of the Database. It shows relationships between entities and their
attributes. An ER model provides a means of communication.
ER diagram of Bank has the following description : 

 Bank have Customer.

 Banks are identified by a name, code, address of main office.
 Banks have branches.
 Branches are identified by a branch_no., branch_name, address.
 Customers are identified by name, cust-id, phone number, address.
 Customer can have one or more accounts.
 Accounts are identified by account_no., acc_type, balance.
 Customer can avail loans.
 Loans are identified by loan_id, loan_type and amount.
 Account and loans are related to bank’s branch.

ER Diagram of Bank Management System :

 This bank ER diagram illustrates key information about bank, including entities
such as branches, customers, accounts, and loans. It allows us to understand the
relationships between entities.
Entities and their Attributes are : 

 Bank Entity : Attributes of Bank Entity are Bank Name, Code and Address. 
Code is Primary Key for Bank Entity.
 Customer Entity : Attributes of Customer Entity are Customer_id, Name, Phone
Number and Address. 
Customer_id is Primary Key for Customer Entity.
 Branch Entity : Attributes of Branch Entity are Branch_id, Name and Address. 
Branch_id is Primary Key for Branch Entity.
 Account Entity : Attributes of Account Entity are Account_number,
Account_Type and Balance. 
Account_number is Primary Key for Account Entity.
 Loan Entity : Attributes of Loan Entity are Loan_id, Loan_Type and Amount. 
Loan_id is Primary Key for Loan Entity.
 Relationships are : 

 Bank has Branches => 1 : N 

One Bank can have many Branches but one Branch can not belong to many
Banks, so the relationship between Bank and Branch is one to many relationship.  

 Branch maintain Accounts => 1 : N 

One Branch can have many Accounts but one Account can not belong to many
Branches, so the relationship between Branch and Account is one to many
relationship. 

 Branch offer Loans => 1 : N 

One Branch can have many Loans but one Loan can not belong to many
Branches, so the relationship between Branch and Loan is one to many
relationship. 

 Account held by Customers => M : N 

One Customer can have more than one Accounts and also One Account can be
held by one or more Customers, so the relationship between Account and
Customers is many to many relationship. 

 Loan availed by Customer => M : N 

(Assume loan can be jointly held by many Customers). 
One Customer can have more than one Loans and also One Loan can be availed
by one or more Customers, so the relationship between Loan and Customers is
many to many relationship.

Conceptual DesignwiththeERModel:

Conceptual design follows requirements analysis, yields a high level

description of data to be stored (conceptual level).
• ER model is a popular model for conceptual design, constructs are
expressive, close to the way people think about applications; supported by
many CASE tools.
• Basic constructs are entities, relationships, and attributes
• Some additional constructs: ISA hierarchies, cardinality ratios,
• There are many variations on ER model constructs
• Several kinds of integrity constraints can be expressed in the ER model:
key constraints, structural constraints, constraints on specializations –
Some of them can be expressed in SQL when translating entity and
relationship types into tables –
Not all constraints can be expressed in the ER model –
Constraints play an important role in determining a good database design for
an application domain.