CHAPTER 1:

FUNDAMENTALS OF DATABASE
MANAGEMENT SYSTEM
DFC 2083 – DATABASE SYSTEM
DATABASE

 Collection of related data that is shared by the

various categories of users to meet the
requirements of an organization’s information.
 ROLE OF DATABASE IN
BUSINESS WORLD

 Application requires data access business rules for

any of the following circumstances:
 Inserting, updating, deleting, and viewing data
 Validating data
 Controlling data security.
 Handling multifiles data access.
Example: Customer Management, Inventory
Tracking, Personnel Database, Analysis
IMPORTANCE OF DATABASES

 Online Television Streaming

 Social Gaming
 Personal Cloud Storage
 Sports
 Finances
 Government Organizations
 Social Media
 ECommerce
 Healthcare
 Weather
DATABASE DEVELOPMENT
PROCESS

Planning

Analysis

Logical Design

Physical Design

Implementation

Maintenance
DATABASE DEVELOPMENT
PROCESS

Planning
Planning Purpose–preliminary understanding
Deliverable–request for study
Analysis

Logical Design

Physical Design

Database activity– Implementation

enterprise modeling
and early conceptual
Maintenance
data modeling
DATABASE DEVELOPMENT
PROCESS

Purpose–through requirements analysis and

Planning structuring
Deliverable–functional system specifications
Analysis
Analysis

Logical Design

Physical Design

Database activity–Thorough Implementation

and integrated conceptual
data modeling
Maintenance
DATABASE DEVELOPMENT
PROCESS
Purpose–information requirements elicitation
Planning and structure
Deliverable–detailed design specifications
Analysis

Logical Design
Logical Design

Physical Design

Database activity– Implementation

logical database design
(transactions, forms,
Maintenance
displays, views, data
integrity and security)
DATABASE DEVELOPMENT
PROCESS
Purpose–develop technology and
Planning organizational specifications
Deliverable–program/data
Analysis structures, technology purchases,
organization redesigns
Logical Design

Physical Design
Physical Design

Database activity– Implementation

physical database design
(define database to DBMS,
Maintenance
physical data organization,
database processing programs)
DATABASE DEVELOPMENT
PROCESS
Purpose–programming, testing, training,
Planning installation, documenting
Deliverable–operational programs,
Analysis documentation, training materials

Logical Design

Physical Design

Database activity–
database implementation, Implementation
Implementation
including coded programs,
documentation, Maintenance
installation and conversion
DATABASE DEVELOPMENT
PROCESS

Planning Purpose–monitor, repair, enhance

Deliverable–periodic audits
Analysis

Logical Design

Physical Design

Database activity–
database maintenance, Implementation
performance analysis
and tuning, error Maintenance
Maintenance
corrections
SHARING CONCEPT DATA IN
DATABASE
 PROPERTIES OF DATABASES

Completeness Ensures that users can access the data they want.

Integrity Ensures that data is both consistent (no contradictory data)

and correct (no invalid data), and ensures that users trust
the database.

Flexibility Ensures that a database can evolve to satisfy changing user

requirements.

Efficiency Ensures that users do not have unduly long response times
when accessing data.

Usability Ensures that data can be accessed and manipulated in ways

which match user requirements.
1.2: DBMS

 Collection of interrelated data

 Set of programs to access the data
 DBMS contains information about a particular enterprise
 DBMS provides an environment that is both convenient and
efficient to use.
 Database Applications:
 Banking: all transactions
 Airlines: reservations, schedules
 Universities: registration, grades
 Sales: customers, products, purchases
 Manufacturing: production, inventory, orders, supply chain
 Human resources: employee records, salaries, tax deductions
 Databases touch all aspects of our lives
PURPOSE OF DATABASE
SYSTEM
 In the early days, database applications were built on top of
file systems
 Drawbacks of using file systems to store data:
 Data redundancy and inconsistency
 Multiple file formats, duplication of information in different files
 Difficulty in accessing data
 Need to write a new program to carry out each new task
 Data isolation — multiple files and formats
 Integrity problems
 Integrity constraints (e.g. account balance > 0) become part of
program code
 Hard to add new constraints or change existing ones
PURPOSE OF DATABASE SYSTEM

 Drawbacks of using file systems (cont.)

 Atomicity of updates
 Failures may leave database in an inconsistent state with partial updates
carried out
 E.g. transfer of funds from one account to another should either complete or
not happen at all
 Concurrent access by multiple users
 Concurrent accessed needed for performance
 Uncontrolled concurrent accesses can lead to inconsistencies
 E.g. two people reading a balance and updating it at the same time

 Security problems
 Database systems offer solutions to all the above problems
VARIOUS COMMON DBMS

 Library
 Hospital
 University
 Tourism
 Organization
Problems: Traditional approach

 Data Security
 Data Redundancy
 Data Isolation
 Program/ Data Dependence
 Concurrent Access Anomalies
Data Security

 The data as maintained in flat files is easily

accessible and therefore not secure.
 Example: the Customer_Transaction file has
details about the total available balance of all
customers.
 A customer wants information about his/her
account balance.
 In a file system it is difficult to give the customer
access to only his/her data in the file.
 Thus enforcing security constraints for entire file
or for certain data items are difficult.
Data Redundancy

 Often the same information is duplicated in two or

more files.
 It may lead to inconsistency
 Assume the same data is repeated in two or more
files. If change is made to data in one file, it is
required that change be made to the data in the
other file as well.
 If this is not done, it will lead to multiple different
values for same data field.
Data Isolation

 Data isolation means that all the related data is

not available in one file.
 Generally, the data scattered in various files, and
the files may be in different formats, therefore
writing new application programs to retrieve the
appropriate data is difficult.
Program/ Data Dependence

 Assume in a banking system there is need to find

out the names of all customers who live within a
particular postal-code area.
 But there is only a program to generate the list of
all customers.
 The bank officer has now two choices: either
obtain the list of all customers and extract the
needed information manually or ask a system
programmer to write the necessary application
program.
 Both the alternatives are obviously unsatisfactory.
Concurrent Access Anomalies

 Many systems allow multiple users to update the data

simultaneously. In such environment, interaction of
concurrent updates may result in inconsistent data.
 Example: Bank account A containing Rs. 6000/-. If two
transactions of withdraw funds( Rs 500/- and Rs 1000/-
respectively) from account about same time, result of the
concurrent executions may leave the account in an incorrect
state.
 Program on the behalf of each withdrawal read the old
balance, reduce amount and write result back.
 If both two programs are concurrent they both may read the
value Rs 6000/-.
 Depending on which one writes the value last, the account
may contain either Rs 5500/- or Rs 5000/-, rather than the
What is the solution?
Importance of having DBMS

 It helps make data management more efficient and

effective.
 A database management system stores, organizes and
manages a large amount of information within a single
software application.
 Use of this system increases efficiency of business
operations and reduces overall costs.
Centralize vs. distributed
database

 Centralize
A single central database
accessed by multiple users.

+ Easier to organise, edit,

query and backup.
- Can be slower because of
high usage / load.
Centralize vs. distributed
database

 Distributed

Database split into multiple

files.

+ Data access and

retrieval faster at nearest
points

- Need to be ensure data

is consistent / synchronised
DATA MODEL

 A data model is a collection of concepts for

describing data.
 A schema is a description of a particular collection
of data, using the a given data model.
 The relational model of data is the most widely
used model today.
 Main concept: relation, basically a table with rows
and columns.
 Every relation has a schema, which describes the
columns, or fields.
The Evolution of Data Models

 Hierarchical
 Network
 Relational
 Entity relationship
 Object oriented
Evolution of Major Data
Models
 The Hierarchical Model—
Evolution

 North American Rockwell was the prime contractor for the Apollo
project which culminated in the moon landing.
 This project required the management of millions of parts – a
complex computer file system was used.
 An audit of the tapes revealed that 60% of the data was redundant
 This led Rockwell to develop an alternate strategy to manage their
data
 The Hierarchical Model—
Evolution

 GUAM (Generalized Update Access Method)

 Based on the recognition that the many smaller parts would
come together as components of still larger components
 In the mid 1960s. IBM joined Rockwell to expand the
capabilities of GUAM, replacing computer tapes with disk
storage
 Information Management System (IMS)
 The result of the joint effort between Rockwell and IBM
 World’s leading mainframe hierarchical database system in
the 1970s and early 1980s
 The Hierarchical Model—
Characteristics

 Basic concepts form the basis for subsequent database

development
 Limitations lead to a different way of looking at database
design
 Basic concepts show up in current data models
 Best understood by examining manufacturing process
A Hierarchical Structure
Hierarchical Structure—
Characteristics
 Each parent can have many children
 Each child has only one parent
 Tree is defined by path that traces parent segments to child
segments, beginning from the left
 Hierarchical path
 Ordered sequencing of segments tracing hierarchical structure
 Preorder traversal or hierarchic sequence
 “Left-list” path
 If Part D is most frequently accessed and updated, change the database
structure to place Part D closer to the left side of the tree
 This will give a shorter traversal
 The Hierarchical Model

 Advantages over a file system

 Conceptual simplicity – easy to understand the model layout
 Database security
 Data independence (a change in a data type will be
automatically cascaded throughout the database by the DBMS,
thereby eliminating the need to make changes in the program
segments that reference the changes data type)
 Database integrity – always a link between parent and child
 Efficiency – very efficient when it contains a large volume of
data in 1:M relationships and whose relationships are fixed over
time
 The Hierarchical Model
(continued)
 Disadvantages over a file system
 Complex implementation – detailed knowledge of the physical data
storage characteristics is required by the designers and programmers
 Difficult to manage – relocation of segments requires application
changes
 Lacks structural independence
 Complex applications programming and use – programmers and end
users must know precisely how the data are physically distributed
within the database
 Implementation limitations – difficult to support M:N relationships
 Lack of standards – no standard DDL and no DML
Child with Multiple Parents
 The Network Model

 Created to
 Represent complex data relationships more effectively
 Improve database performance
 Impose a database standard

 Conference on Data Systems Languages (CODASYL)

 American National Standards Institute (ANSI)
 Database Task Group (DBTG)
Crucial Database Components

 Schema
 Conceptual organization of entire database as viewed by the database
administrator
 Subschema
 Defines database portion “seen” by the application programs that actually
produce the desired information from data contained within the database
 Data Management Language (DML)
 Define data characteristics and data structure in order to manipulate the
data
Data Management
Language Components

 Schema Data Definition Language (DDL)

 Enables database administrator to define schema
components
 Subschema DDL
 Allows application programs to define database
components that will be used
 DML
 Manipulates database contents
 Network Model—Basic
Structure
 Resembles hierarchical model
 Collection of records in 1:M relationships
 A relationship is called a Set
 Composed of at least two record types
 Owner
 Equivalent to the hierarchical model’s parent
 Member
 Equivalent to the hierarchical model’s child
 A record can appear as a member in more than one set i.e., a
member may have multiple owners
A Network Data Model
 The Network Data Model

 Advantages
 Conceptual simplicity
 Handles more relationship types
 Data access flexibility – no need for a preorder traversal
 Promotes database integrity – must first define the owner and then the
member record
 Data independence
 Conformance to standards
The Network Data Model
(continued)

 Disadvantages
 System complexity
 Lack of structural independence
 The Relational Model

 Developed by Codd (IBM) in 1970

 Considered ingenious but impractical in 1970
 Conceptually simple
 Computers lacked power to implement the relational model
 Today, microcomputers can run sophisticated relational
database software
 The Relational Model: Basic
Structure

 Relational Database Management System (RDBMS)

 Performs same basic functions provided by hierarchical and network
DBMS systems, plus other functions
 RDBMS handles all the complex physical detais
 Most important advantage of the RDBMS is its ability to let the
user/designer operate in a human logical environment
The Relational Model:Basic
Structure

 Table (relations)
 Matrix consisting of a series of row/column
intersections
 Related to each other by sharing a common entity
characteristic
 Relational schema
 Visual representation of relational database’s
entities, attributes within those entities, and
relationships between those entities
Linking Relational Tables
 Relational Table

 Stores a collection of related entities

 Resembles a file
 Relational table is purely logical structure
 How data are physically stored in the database is of no concern to
the user or the designer
 This property became the source of a real database revolution
A Relational Schema
 The Relational Model

 Advantages
 Structural independence – changes in the relational data structure do not
affect the DBMS’s data access in any way
 Improved conceptual simplicity by concentrating on the logical view
 Easier database design, implementation, management, and use
 Ad hoc query capability - SQL
 Powerful database management system
The Relational Model
(continued)

 Disadvantages
 Substantial hardware and system software overhead
 Can facilitate poor design and implementation
 May promote “islands of information” problems
The Entity Relationship Model

 Widely accepted and adapted graphical tool for

data modeling
 Introduced by Peter Chen in 1976
 Graphical representation of entities and their
relationships in a database structure
 The Entity Relationship Model
—
Basic Structure
 Entity relationship diagram (ERD)
 Uses graphic representations to model database components
 Entity is mapped to a relational table
 Entity instance (or occurrence) is row in table
 Entity set is collection of like entities
 Connectivity labels types of relationships
 Diamond connected to related entities through a relationship line
The Entity Relationship Model
—
CrowFoot Components
Relationships: The Basic Chen ERD
Relationships:
The Basic Crow’s Foot ERD
 The Entity Relationship Model

 Advantages
 Exceptional conceptual simplicity
 Visual representation
 Effective communication tool
 Integrated with the relational data model
The Entity Relationship Model

 Disadvantages
 Limited constraint representation
 Limited relationship representation
 No data manipulation language
 Loss of information content
THREE-SCHEMA ARCHITECTURE

• ANSI-SPARC – also known as American National

Standards Institute, Standards Planning And
Requirements Committee

Objective :
separate each user’s view of the database from
the way it is physically represented.
THREE-SCHEMA ARCHITECTURE

END USER

USER 1
... USER 2

EXTERNAL
EXTERNAL VIEW 1 EXTERNAL VIEW 2
LEVEL

External/conceptual mapping

CONCEPTUAL CONCEPTUAL
LEVEL SCHEMA

Conceptual/internal mapping

INTERNAL INTERNAL SCHEMA

LEVEL

Data Data Data

STORED DATABASE
THREE-SCHEMA ARCHITECTURE

 Internal Schema
 Physical representation of the database on the
computer.
 Describes the physical storage structure of the
database.
 How the data is stored in the database.
THREE-SCHEMA ARCHITECTURE

 Conceptual Schema
 Describes the structure of the whole database for a
community of users.
 It hides the details of physical storage structures and
concentrates on describing entities, data types,
relationships, user operations, and constraints.
THREE-SCHEMA ARCHITECTURE

 External Schema
 The user’s view of database.
 It includes a number of external schemas or user
views.
 Each external schema describes the part of the
database that a particular user is interested in and
hides the rest of the database from user.
CLIENT-SERVER ARCHITECTURE

• Operate in a networked environment

• Generally the client process requires some resource,

which the server provides to the client

• Clients and servers can reside in the same computer, or

they can be on different computers that are networked
together, usually:
• Client – Workstation (usually a PC) that requests and uses
a service. manages user interface and runs applications.
• Server – Holds database and DBMS.Computer
(PC/mini/mainframe) that provides a service. For DBMS,
server is a database server.
CLIENT-SERVER ARCHITECTURE

 Two-Tier Client-Server Architecture

 In a two-tier architecture, any client can get service
from any server by initiating a request over the
network.
 With two tier client-server architectures, the user
interface is usually located in the user’s desktop and
the services are usually supported by a server that is
a powerful machine that can service many clients.
 Processing is split between the user interface and
the database management server.
CLIENT-SERVER ARCHITECTURE

Two-Tier Client-Server Architecture

 CLIENT-SERVER ARCHITECTURE

 Three-Tier Client-Server Architecture

 To improve performance for large number of users and also
improves flexibility compared to the two tier approach
 In the three-tier architecture, a middleware was added between
the user system interface client environment and the server
environment
 The middleware keeps track of all server locations. It also
translates client’s requests into server understandable form.
 For example, the middleware provides queuing, the client can
deliver its request to the middleware because the middleware
will access the data and return the answer to the client.
CLIENT-SERVER ARCHITECTURE

 The middleware performs many activities such as:

 It knows the addresses of servers. So, based
on client requests, it can locate the servers.
 It can translate between client and server
formats of data and vice versa

 Additional Features – Security:

 Encrypt the data at the server before
transmission
 Decrypt data at the client
CLIENT-SERVER ARCHITECTURE

Three-Tier Client-Server Architecture

CATEGORIES OF DBMS

 Desktop databases:
 Desktop databases are oriented toward single-
user applications and reside on standard
personal computers .
 Desktop databases offer an inexpensive ,
simple solution to many less complex data
storage and manipulation requirements.
 Example: Microsoft Access, FoxPro, FileMaker
Pro, Paradox and Lotus Approach.
 CATEGORIES OF DBMS

 Server Databases
 Server databases contain mechanisms to ensure the
reliability and consistency of data and are geared toward
multi-user applications.
 These databases are designed to run on high-
performance servers.
 Example: Microsoft SQL Server, Oracle and IBM DB2.
BENEFIT OF DESKTOP DATABASES

 Benefit of Desktop Databases

 User-friendly :A user does not need to understand SQL
in order to use them. It usually offer an easy-to-navigate
graphical user interface.

 Offer web solutions. Provide web solutions so that the

user can publish data onto the web in various fashions.

 Lower cost. The cost is lower than server databases.

Example : If you own a copy of Microsoft Office
Professional, you’re already a licensed owner of
Microsoft Access.
BENEFIT OF SERVER DATABASES

 Benefit of Server Databases

 Flexibility. APIs(Application Programmer Interface) are
used for rapid development of custom applications
providing users with a lot of flexibility.

 Powerful Performance. Server databases offer

organizations the ability to manage large amounts of data
and many users.

 Security. All communication must go through the server,

then the setting permissions can be done at the server
level. The permissions determine who can access the
database.
Database Users

 Users are differentiated by the way they expect to interact

with the system
 Application programmers – interact with system through
DML calls
 Sophisticated users – form requests in a database query
language
 Specialized users – write specialized database applications
that do not fit into the traditional data processing
framework
 Naïve users – invoke one of the permanent application
programs that have been written previously
 E.g. people accessing database over the web, bank tellers,
clerical staff
Database Administrator

 Coordinates all the activities of the database system;

the database administrator has a good understanding of
the enterprise’s information resources and needs.
 Database administrator's duties include:
 Schema definition
 Storage structure and access method definition
 Schema and physical organization modification
 Granting user authority to access the database
 Specifying integrity constraints
 Acting as liaison with users
 Monitoring performance and responding to changes in
requirements