Software Banking

& DBMS
 OBJECTIVES
After reading this chapter, the reader
should be able to:
Understand a DBMS and define its components.
Understand the architecture of a DBMS and its levels.
Distinguish between different database models.

Understand the concept of relational database operations

on a relation.
Use Structured Query Language (SQL) to define simple
relations.
14.1
DATABASE
MANAGEMENT
SYSTEM
Figure 14-1

DBMS

 A database management system (DBMS)

defines, creates, and maintains a database.

DBMS components
DBMS components
 Hardware
 The physical computer system that allows physical access to
data
 Software
 The actual program that allows users to access, maintain, and
update physical data
 Data: stored physically on the storage devices
 User: include end users and application programs
 Procedure
 A set of procedures (rules) that should be clearly defined and
followed by the users of the database
14.2
ARCHITECTURE
Figure 14-2

Database
architecture
Database architecture

 Internal level
 The internal level determines where data are actually
stored on the storage device
 Conceptual level
 The conceptual level defines the logical view of the
data
 External level
 The external level interacts directly with the user
14.3
DATABASE
MODELS
Database models

 Hierarchical model: obsolete

 Network model: obsolete
 Relational model
 In a relational model, data are organized in two-
dimensional tables called relations.
Figure 14-3

Hierarchical model
Figure 14-4

Network model: graph

Figure 14-5
Relational model
Converting Entities in Binary
Relationships: One-to-Many

Salesperson Salesperson Commission

Number Name Percentage Year of Hire
SALESPERSON
Customer Customer Salesperson
Number Name HQ City Number
CUSTOMER

7-14
Converting Entities in Binary
Relationships: Many-to-Many

 E-R diagram with the many-to-many binary

relationship and the equivalent diagram using an
associative entity.

7-15
Converting Entities in Binary
Relationships: Many-to-Many

 An E-R diagram with two entities in a many-to-many

relationship converts to three relational tables.

 Each of the two entities converts to a table with its own

attributes but with no foreign keys (regarding this
relationship).

 In addition, there must be a third “many-to-many” table

for the many-to-many relationship.

7-16
14.4
RELATIONAL
MODEL
Figure 14-6

RDBMS

 RDBMS: the relational database management

system (RDBMS)
 Relation: a relation is a 2D table has the following
features:
 Name
 Attributes
 Tuples
DATABASE SYSTEM CONCEPTS
AND ARCHITECTURE
Outline
 File-based Approach
 Database Approach
 Database Systems
 Roles in the Database Environment
 DBMSs
 Three-Schema Architecture and Data Independence
 Database Languages
 Data Models, Database Schema and Database State
 Data Management Systems Framework
 Where are we?
 Extending database capabilities for new applications
 Reading Suggestion:
 [1,2]: Chapters 1, 2

) 20
File-based Approach

 Data is stored in one or more separate

computer files
 Data is then processed by computer
programs - applications

21
File-based Approach

22
File-based Approach

 Problems/Limitations
 Data Redundancy
 Data Inconsistency
 More details: see [2]

23
File-based Approach

 Shared File Approach

 Data (files) is shared between different
applications
 Data redundancy problem is alleviated
 Data inconsistency problem across different
versions of the same file is solved
 Other problems:
 Rigid data structure: If applications have to share files, the file structure that
suits one application might not suit another
 Physical data dependency: If the structure of the data file needs to be changed
in some way, this alteration will need to be reflected in all application programs
that use that data file
 No support of concurrency control: While a data file is being processed by one
application, the file will not be available for other applications or for ad hoc
queries

24
Database Approach

25
Database Approach

 Data
 Known facts that can be recorded and that have
implicit meaning
 Information? Knowledge?
 More: www.whatis.com
 Database: Shared collection of logically
related data and a description of this data,
designed to meet the information needs of an
organization

26
Database Approach
 System catalog (metadata) provides description of data
to enable program–data independence
 Logically related data comprises entities, attributes, and
relationships of an organization’s information
 DataBase Management System (DBMS): a general-
purpose software system that facilitates the processes of
defining, constructing, manipulating, and sharing
databases among various users and applications (or a
software system that enables users to define, create,
maintain, and control access to the database)

27
Database Approach
 Data Definition Language (DDL)
 Permits specification of data types, structures and any data constraints
to be stored in the database
 All specifications are stored in the database
 Data manipulation language (DML).
 Query language: retrieve (query), update (insert, delete, modify)
 Controlled access to database may include:
 a security system
 an integrity system
 a concurrency control system
 a recovery control system
 a user-accessible catalog
 Database System = the Database + DBMS software

28
Database Approach

 Roles in the Database Environment

 Database Administrator (DBA): responsible for authorizing
access to DB, coordinating & monitoring its use, and for acquiring
software and hardware resources as needed
 Database Designers: responsible for identifying the data to be
stored in DB, choosing appropriate structures to represent and
store this data
 Application Programmers
 End Users
 More details: see [1,2]-chapter 1
Database Approach
 Characteristics of the Database Approach
 Self-describing nature of a database system
 Insulation between programs and data, and data abstraction
 Program-data independence + Program-operation independence =
Data abstraction
 A data model is a type of data abstraction
 Support of multiple views of the data
 Sharing of data and multi-user transaction processing
 Other advantages of using the DBMS approach: see [1]-1.6

30
Database Approach

 History of database systems

 First generation: Hierarchical and Network
 Second generation: Relational
 Third generation: Object-Relational, Object-
Oriented
 Brief history of database applications
 see [1]-section 1.7

31
Three-Schema Architecture and Data
Independence

 Objectives of Three-Schema Architecture

 All users should be able to access same data
 Users should not need to know physical database
storage details
 DBA should be able to change database storage
structures without affecting the users’ views
 Internal structure of database should be
unaffected by changes to physical aspects of
storage
 DBA should be able to change conceptual
structure of database without affecting all users
32
 Three-Schema Architecture and Data
Independence

 Three-level architecture and data independence

33
Three-Schema Architecture and Data
Independence

 External Level
 Users’ view of the database
 Describes that part of database that is relevant to
a particular user
 Conceptual Level
 Community view of the database
 Describes what data is stored in database and
relationships among the data

34
Three-Schema Architecture and Data
Independence

 Internal Level
 Physical representation of the database on the
computer.
 Describes how the data is stored in the database

35
Three-Schema Architecture
and Data Independence
 Data Independence is the capacity to change
the schema at one level of a database system
without having to change the schema at the
next higher level
 Logical Data Independence
 Refers to immunity of external schemas to changes
in conceptual schema
 Conceptual schema changes (e.g. addition/removal
of entities) should not require changes to external
schema or rewrites of application programs
36
Three-Schema Architecture
and Data Independence
 Physical Data Independence
 Refers to immunity of conceptual schema to
changes in the internal schema
 Internal schema changes (e.g. using different file
organizations, storage structures/devices) should
not require changes to conceptual or external
schemas

37
Three-Schema Architecture
and Data Independence

38
Database Languages
 Data Definition Language (DDL) allows the DBA or user
to describe and name entities, attributes, and
relationships required for the application plus any
associated integrity and security constraints
 Data Manipulation Language (DML) provides basic data
manipulation operations on data held in the database
 Data Control Language (DCL) defines activities that are
not in the categories of those for the DDL and DML, such
as granting privileges to users, and defining when
proposed changes to a databases should be irrevocably
made

39
Database Languages

 Procedural DML allows user to tell system

exactly how to manipulate data (e.g.,
Network and hierarchical DMLs)
 Non-Procedural DML (declarative language)
allows user to state what data is needed
rather than how it is to be retrieved (e.g.,
SQL, QBE)
 Fourth Generation Languages (4GLs)
 Non-procedural languages: SQL, QBE, etc.
 Application generators, report generators, etc. (see [2])

40
14.7
OTHER
DATABASE
MODELS
Other database models

 Distributed databases
 The data are stored on several computers that
communicate through the Internet.
 Fragmented distributed databases
 Replicated distributed databases
 Object-oriented databases
 An object-oriented database tries to keep the
advantages of the relational model and at the
same time allows applications to access structured
data.
What is E-business?

E-business (electronic business) is the conducting of business on the

[ Internet, not only buying and selling but also servicing customers and
collaborating with business partners.

The processes and tools that allow an organization to use Internet-based

[ technologies and infrastructure, both internally and externally, to conduct
day to day business process operations.

Stands for electronic business and refers to any kind of sales, services,
[ purchasing or commerce on the Internet.

A new-tech jargon word used more for marketing than for technical
description. Most commonly it broadly refers to conducting business over
[ the Internet (email and web) by communicating and perhaps transacting
(buying and selling) with customers, suppliers, and business partners.
What is E-business?

Web

Universal Access

Standards

e-business
Using internet technologies to
transform key business processes

IT

Data

Applications

Core business processes
e-business = Web + I/T 
Reliability, security
and availablitiy
E-business types:

C2C B2B
B2C

CONSUMERS BUSINESS
C2

A
A

B2
ADMINISTRATION
What is Consumers to
Consumers (2C) ?

Abbreviation for consumer-to-consumer commerce; that is,

[ commerce with no middle business people The most notable
examples are Web-based auction and classified as sites. Most
large venues for such models (for example, eBay and
Classifieds2000) are quickly permeated by consumers who
participate so actively and regularly that they become small
businesses for them.

C2C stands for consumer to consumer electronic commerce.

[ The Internet has facilitated new types of C2C although it is
important to note that this kind of commerce -- in the form of
barter, yard sales, flea markets, swap meets, and the like --
has existed since time immemorial. Notably, most of the
highly successful C2C examples using the Internet actually use
some type of corporate intermediary and are thus not strictly
"pure play" examples of C2C.
What is Business to
Business (B2B) ?

B2B stands for "business-to-business," as in businesses

[ doing business with other businesses. The term is most
commonly used in connection with e-commerce and
advertising, when you are targeting businesses as opposed
to consumers.

[ On the Internet, B2B (business-to-business), is the

exchange of products, services, or information between
businesses. B2B is e-commerce between businesses.
B2B Communication using XML over HTTP B2B - the
basics

Business-to-business electronic commerce (B2B) typically

[ takes the form of automated processes between trading
partners and is performed in much higher volumes than
business-to-consumer (B2C) applications.
What is Business to
Consumers (B2C) ?

[ Refers to businesses selling products or services to end-

user consumers.

[ B2B stands for transaction activities involving two business

entities (business-to-business transaction). B2C stands for
transaction activities involving a business and a consumer
(business-to-consumer transaction).

[ Electronic commerce comprises commercial transactions,

involving both organisations and individuals. From the
technical point of view e-commerce is the processing and
transmission of digitised data. E-commerce decreases the
distance between producers and consumers. Consumers
can make their purchase without entering a traditional
shop.
What is Business to
Administration (B2A) ?

Short for business-to-administration, also known as e-

[ government. B2A is the idea that government agencies and
businesses can use central Web sites to conduct business
and interact with each other more efficiently than they
usually can off the Web. FindLaw is an example of a site
offering B2A services -- a single place to locate court
documents, tax forms and filings for many different local,
state and federal government organizations
E-business category

[ E-banks

[ E-trade

[ E-consulting

[ E-engineer
[ E-learning

[ E-mail

[ E-marketing

[ E-transactions
E-business infrastructure

INTERNET ACCESS,
SERVICES,
HARDWARE SOFTWARE E-payment,
CERTIFICATES,
ADVERTISEMENT
ENTERPRISE RESOURCE
PLANNING (ERP) SYSTEMS
What is ERP?

 An ERP system is an attempt to integrate all

functions across a company to a single
computer system that can serve all those
functions’ specific needs.
 “Integration” is the key word for ERP
implementation.
 What is ERP?

 It may also integrate key customers and suppliers

as part of the enterprise’s operation.
 It provides integrated database and custom-
designed report systems.
 It adopts a set of “best practices” for carrying out
all business processes.
Major Reasons for Adopting ERP

 Integrate financial information

 Integrate customer order information
 Standardize and speed up operations
processes
 Reduce inventory
 Standardize Human Resources information
 Potential Benefits of ERP

 Internal Benefits
 Integration of a single source of data
 Common data definition
 A real-time system
 Increased productivity
 Reduced operating costs
 Improved internal communication
 Foundation for future improvement
 Potential Benefits of ERP

 External Benefits
 Improved customer service and order fulfillment
 Improved communication with suppliers and
customers
 Enhanced competitive position
 Increased sales and profits
 ERP Implementation Approaches

 The big bang – install a single ERP system across

the entire organization
 Franchising – Independent ERP systems are
installed in different units linked by common
processes, e.g., bookkeeping.
 Slam dunk – install one or several ERP modules
for phased implementation of key business
processes.
Major Phases of ERP Implementation (Kent
Sandoe, Enterprise Integration)

 Initiation – develop business case, project scope,

and implementation strategy
 Planning – establish implementation team,
determine goals and objectives, establish metrics
 Analysis and process design – analyze and
improve existing processes, map new processes
to be adopted by the system
 Major Phases of ERP Implementation (Kent
Sandoe, Enterprise Integration)

 Realization – install a base system,

customization, and test the system
 Transition – replace the formal system with the
new system, data conversion
 Operation – monitor and improve system
performance, provide continued training and
technical support
Major Challenges to ERP Implementation

 Limitations of ERP technical capabilities

 Inconsistency with existing business processes
 Costs - implementation (hardware, software,
training, consulting) and maintenance
 Impact on organizational structure (front office
vs. back office, product lines, etc.)
 Changes in employee responsibilities
Major Challenges to ERP Implementation

 Flexibility of software system upgrades

 Implementation timelines
 Availability of internal technical knowledge and
resources
 Education and training
 Implementation strategy and execution
 Resistance to change
 ERP Implementation Practices
(APQC Best-Practice Report)

 Change Management
 Redesigned jobs call for higher levels of skills and
accountability
 Change management is viewed as more than just
increased training and communication
 Enterprise-wide systems drive redesigned changes.
 The executive sponsor is the change agent.
 Resistance from the work force (including management)
is the most significant obstacle.
 ERP Implementation Practices
(APQC Best-Practice Report)

 Technology Excellence
 Organizations rely heavily on the ERP package as
the majority of their application configuration.
 Organizations implement ERP packages on time
and within budget
 Organizations centralize support groups within
their IT departments
 New Developments In ERP

 Availability of web-based and wireless ERP

systems
 Adoption of easy-to-install ERP systems
 Linkage to other software systems, e.g., supply
chain management system, e-commerce,
customer relationship management system
CS208

SYSTEM DEVELOPMENT
LIFE CYCLE (SDLC)
 Six Phases of the System
Development Life Cycle
 Preliminary Investigation
 Assesses feasibility and practicality of system
 System Analysis
 Study old system and identify new requirements
 Defines system from user's view
 System Design
 Design new/alternative system
 Defines system from technical view
 Six Phases of the System
Development Life Cycle
 System Development
 New hardware and software is acquired, developed,
and tested
 System Implementation
 System installation and training
 System Operation & Maintenance
 Daily operation
 Periodic evaluation and updating
SDLC Phases

Preliminary
Investigation

System
System Operation Analysis
& Maintenance

System System
Implementation
n Design

System
Development
 Phase 1:
Preliminary Investigation

 Determine if a new system is needed

 Three primary tasks:
 Define the problem
 By observation and interview, determine what
information is needed by whom, when, where and why
 Suggest alternative solutions
 Prepare a short report
 Phase 2:
System Analysis

 In depth study of the existing system to determine

what the new system should do.
 Expand on data gathered in Phase 1
 In addition to observation and interviews, examine:
 Formal lines of authority (org chart)
 Standard operating procedures
 How information flows
 Reasons for any inefficiencies
 Phase 2: System Analysis
Tools Used

 Checklists - list of questions

 Top-down analysis - start with top level
components, break down into smaller parts
through each successive level
 Grid charts - to show relationship between inputs
and outputs
 System flowcharts - charts flow of input data,
processing, and output which show system
elements and interactions
 Phase 2: System Analysis
Documentation Produced

 Complete description of current system and its

problems
 Requirements for for new system including:
 Subject
 Scope
 Objectives
 Benefits
 Possible development schedule
 Phase 3:
System Design
 Uses specifications from the systems analysis to
design alternative systems
 Evaluate alternatives based upon:
 Economic feasibility - Do benefits justify costs?
 Technical feasibility - Is reliable technology and
training available?
 Operational feasibility - Will the managers and users
support it?
 Phase 3: System Design
Tools Used
 Computer-Aided Software Engineering (CASE)
tools are software-based products designed to help
automate the production of information systems.
 Examples:
 Diagramming Tools
 Data Repositories
 Prototyping Tools
 Test Data Generators
 Documentation Tools
 Project Management Tools
 Phase 3: System Design
Documentation Produced

 System Design Report

 Describe Alternatives including:
 Inputs/Outputs
 Processing
 Storage and Backup
 Recommend Top Alternative based upon:
 System Fit into the Organization
 Flexibility for the future
 Costs vs. benefits
 Phase 4:
System Development

 Build the system to the design specifications

 Develop the software
 Purchase off-the-shelf software OR
 Write custom software
 Acquire the hardware
 Test the new system
 Module (unit) test - tests each part of system
 Integration testing - tests system as one unit
 Create manuals for users and operators
 Phase 5:
System Implementation

 Convert from old system to new system

 Train users
 Compile final documentation
 Evaluate the new system
 Phase 5: System Implementation
Types of Conversion
 Direct/plunge/crash approach – entire new system
completely replaces entire old system, in one step
 Parallel approach - both systems are operated side by
side until the new system proves itself
 Pilot approach - launched new system for only one group
within the business -- once new system is operating
smoothly, implementation goes company-wide
 Phased/incremental approach - individual parts of new
system are gradually phased-in over time, using either
crash or parallel for each piece.
 Phase 5: System
Implementation
 User Training
 Ease into system, make them comfortable, and
gain their support
 Most commonly overlooked
 Can be commenced before equipment delivery
 Outside trainers sometimes used
 Phase 6: Operations & Maintenance

 Types of changes:
 Physical repair of the system
 Correction of new bugs found (corrective)
 System adjustments to environmental changes
 Adjustments for users’ changing needs (adaptive)
 Changes to user better techniques when they
become available (perfective)
 Phase 6: Operations & Maintenance

 Evaluation Methods
 Systems audit - performance compared to
original specifications
 Periodic evaluation - “checkups” from time to
time, modifications if necessary
 Deliverables of the SDLC

Approved Feasibility Abort Project

Preliminary
Investigation Study Goto next phase
Problem Goto Previous phase
System
Analysis Specifications

System
Design Design Specifications

System Coded and

Development Tested System
Begin building System System converted
new system Implementation Users trained
System
Maintenance
Operational System
Documentation completed
Waterfall Model
 Requirements – defines needed
information, function, behavior,
performance and interfaces.
 Design – data structures,
software architecture, interface
representations, algorithmic
details.
 Implementation – source code,
database, user documentation,
testing.
Waterfall Strengths

 Easy to understand, easy to use

 Provides structure to inexperienced staff
 Milestones are well understood
 Sets requirements stability
 Good for management control (plan, staff, track)
 Works well when quality is more important than
cost or schedule
 Waterfall Deficiencies
 All requirements must be known upfront
 Deliverables created for each phase are considered
frozen – inhibits flexibility
 Can give a false impression of progress
 Does not reflect problem-solving nature of software
development – iterations of phases
 Integration is one big bang at the end
 Little opportunity for customer to preview the
system (until it may be too late)
When to use the Waterfall
Model
 Requirements are very well known
 Product definition is stable
 Technology is understood
 New version of an existing product
 Porting an existing product to a new platform.
Incremental SDLC Model
 Construct a partial
implementation of a total
system
 Then slowly add increased
functionality
 The incremental model
prioritizes requirements of the
system and then implements
them in groups.
 Each subsequent release of the
system adds function to the
previous release, until all
designed functionality has been
implemented.
Incremental Model Strengths

 Develop high-risk or major functions first

 Each release delivers an operational product
 Customer can respond to each build
 Uses “divide and conquer” breakdown of tasks
 Lowers initial delivery cost
 Initial product delivery is faster
 Customers get important functionality early
 Risk of changing requirements is reduced
Incremental Model Weaknesses

 Requires good planning and design

 Requires early definition of a complete and
fully functional system to allow for the
definition of increments
 Well-defined module interfaces are required
(some will be developed long before others)
 Total cost of the complete system is not
lower