UNIT 1

Introduction To Database
Management System
 Basic Definitions

 Data: Known facts that can be recorded and have an

implicit meaning.
 Database: Systematic collection of related data.
 Database Management System (DBMS): A collection of
software to facilitate the creation and maintenance of a DB
 Database System: The DBMS software together with the
data. Sometimes, applications are also included.
 Database Example
• College Database
ü Student file
ü Course file
ü Section file
ü Grade-Report file
ü Pre-requisite file etc.
Difference between Traditional File
Processing Vs. DBMS
 File Processing Systems
Billing Purchasing
Program Program

Accounts Buyer Inventory Vendor

Customer
receivable file file file
file
file

Accounts_Payable Sales Order Processing Payroll

Program Program Program

Inventory Employee
Vendor Invoice Customer
file file
file file file
 Database Approach
Order Dept. Accounting Payroll
Dept. Dept.

Program Program Program

A B C

Ordering
Invoicing Payroll
filing
System System
System

Back Inventory Customer Inventory Employee

Orders Master Master Pricing Master
file file file file file
 Characteristics of Database

• Self-describing nature

• Insulation between program, data and data

abstraction

• Support for multiple views of data

• Sharing of data and Multiuser Transaction

processing
 Actors on the Scene
(job involves day-to-day use of d/b)

• Database Administrator

• Database Designer

• End User

• System Analysts and Application Programmers

 Workers Behind the Scene
(People responsible for development & operation of DBMS)

• DBMS system designers & implementers

• Tool Developers
ü For performance monitoring (SQL Server Profiler)
ü Natural language or graphical interface (SQL Lite
D/b browser)

• Operators & maintenance

 Advantages of DBMS
ü Controlling Redundancy
ü Restricting unauthorized access
ü Providing storage structures for efficient query
processing
ü Query optimization
ü Providing backup & recovery
ü Representing complex relations and data
ü Enforcing integrity constraints
 Advantages (Continued..)
ü Permitting Inferencing and actions using rules
ü Additional advantages
§ Potential for enforcing standards
§ Reduced application development time
§ Flexibility
§ Availability of up-to-date information
§ Economies of scale
 DBMS Vs. File System
Difference File System DBMS
Factor
Definition Is an abstraction to store, retrieve, A collection of interrelated data
manage and update a set of files and a set of programs to
access it
Data Each user defines and A single repository of data is
Redundancy implements needed file for a maintained that is defined once
specific application and accessed by many users
Sharing of data Doesn’t allow sharing of data or Data can be shared easily due
data sharing is very complex to centralized storage
Data When data is redundant it is Less data redundancy so data
consistency difficult to update remains consistent
Difficult to It becomes difficult as need to Very easy and user friendly.
search/access refer multiple files Query operations are already
data available
 DBMS Vs. File System

Difference File System DBMS

Factor
Data Isolation No standard format of data, data Due to centralized system,
is scattered in various files format of similar type of data
remains same
Data Integrity Data in d/b must follow or satisfy Maintains data integrity by
some rules or constraints to avoid providing constraints
invalid data entry
Security No or less security. Majorly High level of security as
problems provided are locks, guards encryption, passwords
Concurrent File system doesn’t provide any Provides functionality for
access remedy for it concurrent access of
anomalies transactions
 A Brief History D/B Applications
ü Early D/b applications using hierarchical &
network systems
ü Providing application flexibility with relational
databases
ü Object oriented applications & the need for
more complex databases
ü Interchanging data on the web for E-
commerce
ü Extending database capabilities for new
applications
 Hierarchical System
ü Uses one-to-many relationship

ü Presents data in tree-like structure

ü E.g. IBM’s IMS(Information management system), .xml file

01 LIBRARY-SEGMENT.
05 BOOK-ID PIC X(5).
05 ISSUE-DATE PIC X(10).
05 RETURN-DATE PIC X(10).
05 STUDENT-ID PIC A(25).
01 BOOK-SEGMENT.
05 BOOK-ID PIC X(5).
05 BOOK-NAME PIC A(30).
05 AUTHOR PIC A(25).
01 STUDENT-SEGMENT.
05 STUDENT-ID PIC X(5).
05 STUDENT-NAME PIC A(25).
05 DIVISION PIC X(10).
 Disadvantages (When not to use DBMS)

ü Huge investment in s/w, h/w & training

ü Overhead for providing security, concurrency

control, recovery, and integrity functions

ü Simple, well defined, not expected to change

applications

ü Multiple user access to data is not required

 Contents
 Entity types, Entity sets, Attributes, Keys
 Relationship types, Relationship sets,
roles, Structural Constraints
 Strong and weak entity
 E-R diagram
 Relationship types of degree higher than 2
 Enhanced ER model
 UML (Unified Modelling Language)
 E-R Model
 High level conceptual data model
 No implementation details
 Used to communicate to non technical
users
 Describes the data as entities,relationships
and attributes.
 Database application - “COMPANY”
1. Company is organized into departments. Each department
has unique name, number and particular employee who manages it.
We keep track of the start date when that employee began
managing the department. A department may have several locations.

Requirements
 2. Department controls a number of projects, each of
which has
a unique name, a unique number and a single locatio
n.
3. We need to store each employee's name, number, add
ress,
salary, gender,and date of birth. An employee is assign
ed to one
department but may work on several projects, which
are not
necessarily controlled by the same department.

Requirements
 4. We want to keep track of the dependents of each
employee for insurance purposes. We keep each
dependent's first name, Gender, date of birth
and relationship to employee

Requirements
 5. We keep track of the number of hours per week
that an employee works on each project. We also
keep track of the direct supervisor of each employee

Requirements
 Basic Concepts
 Entity:
 Thing in the real world with an independent
existence.
 e.g. A particular person, a car
A Company, a job, a university course
 Attributes:
 Particular properties that describe an entity
 ATOMIC
COMPOSITE ATTRIBUTE
ATTRIBUTE

SINGLE-VALUED
MNAME LNAME ATTRIBUTE
GENDER
FNAME
NAME SALARY

ENO PHONE
EMPLOYEE NO

DOB
STORED
ATTRIBUTE AGE
MULTI-VALUED
ADDRESS ATTRIBUTE

DERIVED
ATTRIBUTE
 Composite Vs Atomic/Simple
Attributes
Atomic Attributes : Attributes that are not divisible.
ü Value of composite attribute is concatenation of the
values of constituent atomic attributes
Example Pin Number

Composite Attributes : Can be divided into

smaller sub parts which represent more basic
attributes with independent meanings
Example Fullname
Single Valued Vs Multi-Valued
Attributes
Single Valued Attributes : Attributes having single
value for a particular entity. E.g. salary, DOB etc.

Multi-Valued Attributes : Attributes having a set of

values for a particular entity. E.g. phone number,
color of a car
 Stored Vs Derived Attributes
ü Two or more attribute values are related.
ü E.g. age and DOB of a person.
ü For a person age of a person can be derived from
DOB of a person
 Complex Attributes
ü A group of composite and multivalued attributes
ü Composite attributes represented using ( ) where
every atomic attribute separated by ,
ü Multivalued attributes represented using { }
ü E.g. AddressPhone for a person
{AddressPhone( {Phone (AreaCode, PhoneNo)} ,
Address(StreetAddress(Number, Street,
AptNo), City, State, Zip) ) }
 Complex Attribute
AddressPhone

Composite Composite
Phone MultiValued
Address

AreaCode PhoneNo StreetAddress City State Zip

Atomic Attribute Composite Attribute Atomic Atomic
Atomic Attribute Atomic

Number Street AptNo

Atomic Atomic Atomic

{AddressPhone( {Phone (AreaCode, PhoneNo)} ,

Address(StreetAddress(Number, Street, AptNo),
City, State, Zip) ) }
 Null Values
ü An entity doesn’t have an applicable value
for some attribute then special value called
‘Null’ is created.
Value of
attribute is
Use of Null unknown
Values
Not applicable
 Entity Type
ü A collection (or set) of entities that have same
attributes
ü Is described by its name and attributes.
 Entity Set
ü Collection of all entities of a particular entity
type at the particular moment of a time

ü Usually referred using the same name as the

entity name
 Key Attribute
ü Important constraint on entities of an entity
type

ü Uniqueness constraint

ü E.g. employee_name for an Employee entity

type
Value Sets (Domains) of Attributes

ü Value assigned to attribute of an individual

entity is selected from Value sets or
Domains of Attributes.

ü E.g. Age of an employee

ü Value sets are typically specified using the

basic data types e.g. integer, date, time etc.
 Notations
§ Entity Type
§ Attribute
§ Key Attribute
§ Multi Valued
attribute
§ Composite
attribute
 RELATIONSHIP TYPE

EMPLOYEE WORKS_FOR DEPARTMENT

r1
d1
e1
e2 r2 d2

e3 d3
r3
e4 RELATIONSHIPd4
SET
r4
e5 .
. .
r5
. .
. .
RELATIONSHIP
.
INSTANCES .
Relationship Type, Set and Instances

v Relationship Type ‘R’ among entity types E1,E2,..En

defines a set of associations among entities from
these entity types
v Relationship set ‘R’ is a set of relationship
instances rp where each ri (from rp) associates n
individual entities (e1,e2,…en) and each entity ej in ri
is belong to Entity type Ej, 1 ≤ j ≤ n
 Relationship Degree

ü Number of participating entity types

ü WORKS_FOR relationship degree = 2, Binary
ü Relationship degree = 3, Ternary
 Constraints on Relationship Types
ü Which limit the possible combinations of entities that
may participate in the corresponding relationship set

Relationship Constraints

Participation
Cardinality Ratio
Constraints

Structural Constraints
 Cardinality Ratio

ü Number of maximum relationship instances

that an entity can participate in.

Entity Types Relationship Cardinality

Type Ratio
DEPARTMENT : EMPLOYEE WORK_ON N:1
EMPLOYEE : DEPARTMENT MANAGES 1:1
EMPLOYEE : PROJECT WORKS_ON M:N
 Participation Constraints and
Existence Dependencies
ü Participation constraint specifies whether the
existence of an entity depends on whether it is
related to another entity using the relationship
type
ü Also called as Minimum cardinality constraint
 Types of Participation Constraints

ü Total : Every entity from one entity type must be

related to another entity type via relationship type
e.g Every employee must work for a department. So,
employee entity exists iff it participates in at least one
WORKS_ON relationship instance
ü Also called as Existence Dependency
ü Partial : Some of entities from one entity type
are related to another entity type via relationship
type
e.g Not every employee manages the
department so, participation of EMPLOYEE in the
MANAGES relationship type is partial
 Identifying Relationship Types

Relationship Type Cardinality Participating entities

Ratio
MANAGES 1:1 EMPLOYEE : DEPARTMENT

WORKS_FOR 1:N DEPARTMENT : EMPLOYEE

CONTROLS 1:N DEPARTMENT : PROJECT

SUPERVISION 1:N EMPLOYEE(SUPERVISOR) :

EMPLOYEE(SUPERVISEE)
WORKS_ON M:N EMPLOYEE : PROJECT

DEPENDENTS_OF 1:N EMPLOYEE : DEPENDENT