UNIT 1

UNIT - I Database System Applications: A Historical Perspective, File Systems versus a DBMS, the Data Model, Levels of
Abstraction in a DBMS, Data Independence, Structure of a DBMS Introduction to Database Design: Database Design and
ER Diagrams, Entities, Attributes, and Entity Sets, Relationships and Relationship Sets, Additional Features of the ER
Model, Conceptual Design With the ER Model

- Applications of Database System

The applications of database systems are wide and it never ends up. Some of the application areas include
1. University 2. Banking 3. Hospital 4. Telecommunication 5. Finance
6. Sales and marketing

- History of database
The database system has a long history over the period the technology for database storage and access method
has been changed.
1. During 1950’s, during this period, magnetic tapes are used as storage media. Data will be stored and
processed on the magnetic tapes by using sequential access. Therefore, processing speed is less during
1960’s to 1970’s.
2. During this period, the usage of hard disk has changed the scenario of data storage and data processing.
The hard disk will provide direct access of the data. Therefore, process will become faster.
3. During 1970’s, E.F. Codd introduced the relational model and therefore many relational DB has been
started.
4. During 1980’s, during this period, many relational DB such as oracle, SQL server, IBM DML has been
introduced in the market and many researchers start working on disturbed databases during 1990’s many
database vendors provided many distributed databases into market and the usage of SQL has provided a
convenient environment for the user to work with database system.

- File System vs Database system

In early days, before database systems were introduced, users had to store their data in files and
retrieve the data from the files by writing different application programs this technique is known as File
Processing System (FPS).
File Processing System is suitable with the collection of files is less in number and data is limited.
When the file size increases, it becomes difficult to maintain such data with FPS.
* Drawbacks of File Processing System
a. Data Redundancy b. Data inconsistency c. Data Integrity
d. Data Isolation e. Data Security f. Difficulty in accessing the data
a. Data Redundancy:
It means duplication of the data. It leads to the wastage of storage space. This happens because no
 validation methods available in File Processing System.
b. Data Inconsistency:
Data Redundancy leads to a problem known as Data Inconsistency i.e. multiple copies of the same
data may no longer agree with each other.
c. Data Integrity:
It refers to correctness. Integrity problem will arise due to the lack of integrity checks such as student
age should not be less than 18 etc.
d. Data Isolation:
In File System, data is distributed in different locations and to retrieve the data from these isolated
files, large application programs need to be written.
e. Data Security:
In File System, the files can be password protected sometimes we want to give the access to few
records from a file then security becomes difficult.
f. Difficulty in accessing the data:
In File System, efficient data access methods are not available hence accessing the data is difficult.

- View of Data
Database is a collection of large volumes of data the user does not always require the entire data from the
 database. Therefore, it is the responsibility of the database to provide the required data to the user.

- Data abstraction
Data abstraction refers to the way of representing the essential features and hiding background details or
complexities from the user.

- Need for the data abstraction

Data abstraction is necessary because user is not computer trained or expert. To make user job simpler
different levels of data abstraction are provided so that user will feel convenient to work with the database.

- Levels of abstraction
External View View View View

Conceptual Logical Level

Level

Internal Level Physical Level

There are 3 levels of data abstraction

1. Physical Level 2. Logical Level 3. View Level
1. Physical Level
a. It is also known as internal level or lower level.
b. It describes about how the data is actually stored in the database (Implementation or storage
structure).
2. Logical Level
a. It is also known as conceptual level.
b. It describes what data is actually stored in the database and relationship among the data.
c. Logical design is taken by DBA (Data Base Administrator).

3. View Level
a. It is also known as external level.
b. It describes the part of entire database in the form of different views by different users.

- Instance
A database instance is a set of memory structure and background processes that access a set of database
files. The process can be shared by all users. The memory structure that are used to store most queried data
from database. This helps up to improve database performance by decreasing the amount of I/O performed
against data file.

- Schema/Scheme
The overall design of the database is known as the database schema. According to the levels of data
abstractions, there are 3 types of schemas available.
1. Physical Scheme 2. Logical Scheme 3. Sub Scheme
 1. Physical Scheme: It describes the structure of data at physical level.
2. Logical Scheme: It describes the structure of data at logical level.
3. Sub Scheme: It describes different values of the users interacting with the database.

- Data independence
It is defined as the ability to modify data at one level without effecting at the next level. Data independence is
of 2 types
1. Physical data independence 2. Logical data independence
1. Physical Data Independence:
The ability to modify the physical structure at the physical level without effecting the next level (Logical
level) is known as Physical Data Independence.
2. Logical Data Independence:
The ability to modify the data at the logical level without effecting the next level (View level/External level)
is known as Logical Data Independence.
Note: Logical Data Independence is more difficult to implement than Physical Data Independence.

- Data Models
Data model is the way to represent the data within the database. Data model is a collection of conceptual tools
for describing:
1. For describing data
2. The relationship among data
3. Data semantic
4. The consistency constraints
Different data models are available. The classification of data model is shown below

Data
Model
Object based Record based Physical
data model Data Model data
E-R Model Hierarchical model
Network
Relational Unifying
Data model is mainly classified into 3 categories: Frame
Memory
1. Object based data model 2. Record based data model 3. Physical data model
1. Object based data model:
The object-based data model deals with the real-world object and relation among the objects. One of the
popular models to represent object-based model in E-R model.
E-R Model (Entity-Relationship):
The overall design of the database is represented graphically using entity-relationship diagram. The E-R
model shows entities, relations among entities in a diagrammatic fashion.
Ex: Entity: Student Entity: Class
 Attributes: Roll no. Attributes: Room no.
Name No. of seats
Address Location
Section

Roll No. Name Room No.

Location

Student Enroll Class

Section Address No. of seats

2. Record based data model:

The record-based data model stores the data in the form of fixed format record where each record
maybe having fixed length. Record-based data model contains 3 models
a. Hierarchical model b. Network model c. Relational model
a. Hierarchical Model:
In this model, the data and relationship among data is represented by using records and link or
pointer. This model is generally in the form of tree like structure.

b. Network Model:
In this model, data and relation among data is represented using records and pointers. This model is
generally represented in graph like structure.

c. Relational Model:
i. It is the most popular data model used nowadays.
ii. It was developed in year 1970 by EF Codd.
iii. The main constraint is to represent the relational model is in the form of relation (Table).
iv. A relation is a combination of rows and columns.
v. Each relation represents a relational schema and relational instance.

- Database system structure:

 Native Users Application Sophisticate Database
d
(Tellers, Agents Programmers Administrator
etc.) Users s

Applicatio Applicatio Administratio

n n Query Tools n
Interfaces Programs Tools

Compiler
and DML DDL Interpreter
Queries
Linker Query
Processo
Application Queries r
DML Compiler
Program Evaluatio
Cod Engine
Object
e n

Authorizatio
File Buffer n
Manager Manager
and Integrity Storage
Manager Manage
Transition r
Manager

Indices Statistical Data

Disk Storage

Data Files Data Dictionary

- Database User & Database Administrator:

The people who work with the database is categorised into 2 types:
1. Database User 2. Database Administrator
1. Database User
The database users are categorised into 4 types according to the way they are expected to interact with
 database:
a. Native User (Unsophisticated) b. Application Programmers
c. Sophisticated User (Analyst) d. Specialized User

a. Native User (Unsophisticated):

* Native user also known as unsophisticated user or unskilled user.
* They interact with the database by using an API (Application Program Interface).
Ex: The users of ATM i.e. Automatic Telling Machine are categories as native user, teller, agents.
b. Application Programmers:
Application programmers are the skilled users who write certain application programs to interact with
the database. They use RAD (Rapid Application Development) tools to write the application programs.
They use the interface such as forms reports.
c. Sophisticated User:
* Sophisticated users also known as analyst.
* They interact with the database by using DML queries.
* These DML queries will be compiled using DML compiler and evaluated using query evaluation
engine.
d. Specialized User:
The specialized user are the sophisticated users who write some complex application programs such
as Computer Aided Design (CAD), Artificial Intelligence (AI), expert system & some graphics-based
application.
2. Database Administrator (DBA):
DBA is a person who has the centralised control over the entire database.
* Functions of DBA
a. Scheme definition:
The DBA is responsible for defining the schema (overall design) of the database.
b. Storage structure of access method definition:
The DBA is responsible to define the storage structure (logical design) and access method
(Retrieval Technology).
c. Physical organisation modification:
The DBA is responsible for the modification of the physical organisation of the database.
d. Granting authorization for data access:
The DBA will provide the access permissions to the user so that only the authorised users will
access the database.
e. Regular Maintenance:
i. Taking backup:
The DBA will take the backup of the database at regular intervals of time to be used for
recovery purpose.
ii. Monitoring the jobs:
The DBA will monitor the running jobs in order to maintain the performance of the system.
iii. Monitoring the disk space:
 The DBA will monitor the file space allocation so that the new jobs will get the needed space
in the disk.

- Database Architecture:
The functional components of database architecture are categorised into 2 types:
1. Query processor 2. Storage manager
1. Query processor:
Query processor is a major component of database architecture. It includes the following components:
a. DML Compiler:
The DML compiler is used to compile the DML queries submitted by the user and generate low level
instruction understood by query evaluation engine.
b. DDL Interpreter:
The DDL interpreter will execute the DDL statements given by the user and store the result in a special
file called Data Dictionary.
c. Query evaluation engine:
The query evaluation will execute or evaluate low level instructions by DML compiler.
2. Storage manager:
The storage manager is a program module that acts as an interface between the query processor and low-
level data stored in the disk storage. It includes the following components:
a. Buffer manager:
The buffer manager is responsible for allocating temporary storage for the files.
b. File manager:
The file manager will take care of the files being stored in the database.
c. Authorization & Integrity manager:
This component is responsible for giving the authorization DAP (Data Access Permission) and
maintaining integrity of the database.
d. Transaction Manager:
It is responsible for managing the transaction within the database system. A transaction is a logical
unit of work done by the user.
Ex: Credit & debit operation in bank transaction.
The storage will maintain several data structures as part of physical storage implementation.
a. Indices (indexes): for faster retrieval of data.
b. Data files: It is a collection of data stored in the files.
c. Data Dictionary: It is a container for meta data.
d. Statistical data: It maintain the statistical information of database users.

- Database Design
The database design process consistence of the following steps:
1. Requirement Analysis (Data Gathering)
2. Conceptual Design (ER Model)
3. Logical Design (Relational Model)
 4. Schema Refinement (Normalization Techniques)
5. Physical Database Design (index, clusters etc)
6. Database Tuning
7. Security Design (Authorization)

- ER Model beyond ER Design

The ER model consistence of various entity objects, attributes of entity properties and relationship among the
entities are represented in a diagrammatic fashion is known as entity relationship model.
Ex: The company database wants to maintain the following information about their emp and department.
The emp (E_ID, E_Name, E_Sal, Desig, Ph_No), Dept (D_No, D_Name, Budget). Identify the key attributes
and the relationship among the entity is as follows
There are 2 conditions
1. Emp works in department
2. Each department is managed by the employee
Draw a neat sketch diagram for the above information

E_ID E_Name D_No D_Nam

Works e

Emp Dep
t
Manage
d
E_Sal Desig Ph_No Budge
t

- Additional features of ER model

The ER model consist of the following features
1. Key constrains 2. Participation constrains 3. Weak entities 4. Class hierarchy
5. Aggregation 6. Key constraint for ternary relationship

1. Key Constraints:
Consider the following ER – diagram given below
 E_ID E_Name D_No D_Nam
e

Emp Manage Dep

d t

E_Sal Desig Budge

t
In the above ER diagram, there is a restriction that each department is managed by an employee
(Manager). This restriction is an example for the key constraints. The key constraints are represented
with an arrow in the diagram.
2. Participation constraints:
The participation is of 2 types
a. Total participation
b. Partial participation
Consider the ER diagram given above, in the ER diagram, the dept entity is totally participating
with the managers relationship. This participation is known as total participation.
If the participation is not total, then it is said to be partial. In the above ER diagram, the emp entity
is partially participating with the manages relationship. Hence, it is called as partial participation.
3. Weak Entities:
A weak entity is an entity that does not contain a primary key. It is represented with double rectangle box
Consider the given ER diagram
Partial key or

discriminated
E_ID E_Name Nam key Ag
e e

Emp Policie Dependen

s t

E_Sal

In the given example, dependent is a weak entity.

4. Class Hierarchy:
Sometimes it is common to represent entity into subclass using ‘IS A’ relationship. This concept is known
as a class hierarchy. The class hierarchy represents the inheritance concept where a super class may have
some sub classes. The class hierarchy is represented in 2 ways
a. Generalization b. Specialization
 e_nam
e_n e
o e_sa
l
Emp

(Overlap constrains)

(Covering constrains)
Is
Wage ID
Specialization

Generalization
s A

Hourly_Emps Contract_Emps

Hourly_worked Wage
s
a. Generalization:
Generalization is the process of finding some common properties of two sub classes having a
super class entity. In the above example, hourly emp, contract emp are generalized in emp.
b. Specialization:
The process of sub-dividing a super class entity into sub class entity is known as specialization.
In the above example, the super class entity emp is having sub class entities – hourly employee and
contract employee.
There are 2 constrains w.r.t generalization & specialization
i. Overlap Constraint:
The overlap constraint determines whether two subclass entities are allowed to have
common attributes of superclass.
ii. Covering Constraint:
Covering constraint determines whether the subclass entities include all the attributes of
super class.
5. Aggregation
E_No E_Name E_Desig

Emp

Monitor until
s

since
D_No D_Nam P_ID
e
Dept Sponsors Project Start
s data

budge
t
In ER diagram, we represent relationship as an association among 2 entities. Sometimes we want
to represent relationship among relationships. This will be done using a concept known as Aggregation.
In the above example, the relationship set sponsors is associated with the relationship monitors.
The aggregation is represented by considering the relationship set sponsored among 2 entities,
 departments, projects as an entity set. It is shown with a dotted box in the diagram.
- Features of Aggregation
Aggregation is used to express relationship among relationship
6. Key constraints for ternary relationship
E_No E_Name D_No D_Nam
e
Emp Works in Dep
t

E_Sal Budge
t
from Location to

In the given ER diagram, an employee works in a department and in a single location. This
restriction for ternary relationship is represented with the key constraints using an arrow from employees
to work in relationship.

- Conceptual design with the ER Model

Conceptual design is the process of defining a high-level description of the data using ER model. There are
different design issues while designing conceptual design with ER model.
1. Entity vs Attribute
Sometimes an attribute of an entity set can be better represented as entities. Consider the ER diagram.

E_No E_Name from to D_No D_Nam

e

Emp Works in Dep

t
E_Desig Budge
t

E_No E_Name D_No D_Nam

e

Emp Works in Dep

t

E_Desig Budge
t
from Duration to

2. Entity vs Relationship
Sometimes an object will be better expressed as an entity rather than a relation.
E_Name since budge D_No D_Nam
E_No t e

Emp Manage Dep

s t
E_Desig Location
 E_Name E_Desig D_No D_Nam
e
E_No Emp Manage Dep
s t

Is Location

A
since Manage budge
r t
3. Binary vs Ternary
Sometimes a non - binary relationship can be expressed using distinct binary relations. Consider the
givenER diagram policies with ternary relation.
E_Name D_Nam
E_No e Age

Emp Covers Dependen

t
E_Desig P_ID Amoun
Policie
s t

D_Nam
E_No E_Name e Age

Emp Dependen
t

E_Desig Purchas Beneficiar

e y

P_ID Policie Amoun

s t

4. Aggregation vs Ternary
Sometimes an ER diagram with aggregation can be best expressed as ternary relation.
E_Name
E_No

D_Nam E_Sal
Emp Amoun
D_No e P_ID t

Dependen Monitor Project

t s s
Budge
t
Entity
Any thing that has an independent existence and about which we collect data. It is also known as entity type.
In ER modeling, notation for entity is given below.

Entity instance

Entity instance is a particular member of the entity type.

Example for entity instance : A particular employee
Regular Entity
An entity which has its own key attribute is a regular entity.
Example for regular entity : Employee.
Weak entity
An entity which depends on other entity for its existence and doesn't have any key attribute of its own is a weak
entity.
Example for a weak entity : In a parent/child relationship, a parent is considered as a strong entity and the child
is a weak entity.
In ER modeling, notation for weak entity is given below.

Attributes

Properties/characteristics which describe entities are called attributes.

In ER modeling, notation for attribute is given below.

Domain of Attributes

The set of possible values that an attribute can take is called the domain of the attribute. For example, the
attribute day may take any value from the set {Monday, Tuesday ... Friday}. Hence this set can be termed as the
domain of the attribute day.
Key attribute

The attribute (or combination of attributes) which is unique for every entity instance is called key attribute.
E.g the employee_id of an employee, pan_card_number of a person etc.If the key attribute consists of two or
more attributes in combination, it is called a composite key.
In ER modeling, notation for key attribute is given below.

Simple attribute

If an attribute cannot be divided into simpler components, it is a simple attribute.

Example for simple attribute : employee_id of an employee.
Composite attribute
If an attribute can be split into components, it is called a composite attribute.
Example for composite attribute : Name of the employee which can be split into First_name, Middle_name, and
Last_name.
Single valued Attributes
If an attribute can take only a single value for each entity instance, it is a single valued attribute.
example for single valued attribute : age of a student. It can take only one value for a particular student.
Multi-valued Attributes
If an attribute can take more than one value for each entity instance, it is a multi-valued attribute. Multi-valued
example for multi valued attribute : telephone number of an employee, a particular employee may have multiple
telephone numbers.
In ER modeling, notation for multi-valued attribute is given below.

Stored Attribute

An attribute which need to be stored permanently is a stored attribute

Example for stored attribute : name of a student
Derived Attribute

An attribute which can be calculated or derived based on other attributes is a derived attribute.
Example for derived attribute : age of employee which can be calculated from date of birth and current date.
In ER modeling, notation for derived attribute is given below.

Relationships

Associations between entities are called relationships

Example : An employee works for an organization. Here "works for" is a relation between the entities employee
and organization.
In ER modeling, notation for relationship is given below.

However in ER Modeling, To connect a weak Entity with others, you should use a weak relationship notation as
given below
Degree of a Relationship

Degree of a relationship is the number of entity types involved. The n-ary relationship is the general form for
degree n. Special cases are unary, binary, and ternary ,where the degree is 1, 2, and 3, respectively.
Example for unary relationship : An employee ia a manager of another employee
Example for binary relationship : An employee works-for department.
Example for ternary relationship : customer purchase item from a shop keeper
Cardinality of a Relationship

Relationship cardinalities specify how many of each entity type is allowed. Relationships can have four possible
connectivities as given below.
1. One to one (1:1) relationship
2. One to many (1:N) relationship
3. Many to one (M:1) relationship
4. Many to many (M:N) relationship
The minimum and maximum values of this connectivity is called the cardinality of the relationship
Example for Cardinality – One-to-One (1:1)

Employee is assigned with a parking space.

One employee is assigned with only one parking space and one parking space is assigned to only one
employee. Hence it is a 1:1 relationship and cardinality is One-To-One (1:1)
In ER modeling, this can be mentioned using notations as given below
Example for Cardinality – One-to-Many (1:N)

Organization has employees

One organization can have many employees , but one employee works in only one organization. Hence it is a
1:N relationship and cardinality is One-To-Many (1:N)
In ER modeling, this can be mentioned using notations as given below

Example for Cardinality – Many-to-One (M :1)

It is the reverse of the One to Many relationship. employee works in organization

One employee works in only one organization But one organization can have many employees. Hence it is a
M:1 relationship and cardinality is Many-to-One (M :1)
In ER modeling, this can be mentioned using notations as given below.

Cardinality – Many-to-Many (M:N)

Students enrolls for courses

One student can enroll for many courses and one course can be enrolled by many students. Hence it is a M:N
relationship and cardinality is Many-to-Many (M:N)
In ER modeling, this can be mentioned using notations as given below

Relationship Participation

1. Total
In total participation, every entity instance will be connected through the relationship to another instance of the
other participating entity types
2. Partial
Example for relationship participation
Consider the relationship - Employee is head of the department.
Here all employees will not be the head of the department. Only one employee will be the head of the
department. In other words, only few instances of employee entity participate in the above relationship. So
employee entity's participation is partial in the said relationship.
However each department will be headed by some employee. So department entity's participation is total in the
said relationship.
Advantages and Disadvantages of ER Modeling ( Merits and Demerits of ER
Modeling )Advantages

1. ER Modeling is simple and easily understandable. It is represented in business users language and
it can be understood by non-technical specialist.
2. Intuitive and helps in Physical Database creation.
3. Can be generalized and specialized based on needs.
4. Can help in database design.
5. Gives a higher level description of the system.
Disadvantages

1. Physical design derived from E-R Model may have some amount of ambiguities or inconsistency.
2. Sometime diagrams may lead to misinterpretations