Transcript The Database Environment

Chapter 1:
The Database Environment
© Prentice Hall
1
Objectives








Definition of terms
Explain growth and importance of databases
Name limitations of conventional file processing
Identify five categories of databases
Explain advantages of databases
Identify costs and risks of databases
List components of database environment
Describe evolution of database systems
Chapter 1 & 2
© Prentice Hall
2
Definitions

Data: stored representations of meaningful
objects and events





Structured: numbers, text, dates
Unstructured: images, video, documents
Database: organized collection of logically
related data
Information: data processed to increase
knowledge in the person using the data
Metadata: data that describes the properties and
context of user data
Chapter 1 & 2
© Prentice Hall
3
Systems and Procedures



Product flow and information flow
Product flow: the flow of raw materials into
assemblies and finally into finished goods.
Information flow: the creation of movement
of the administrative and operational
documentation necessary for product flow.
Chapter 1 & 2
© Prentice Hall
4
Product flow and Information flow
Customers
Billing
(7)
Employees
Collection
(8)
Sales
(5)
Inventory
(3)
Vendors
Purchasing
(1)
Production
(4)
Distribution
(6)

Paying
(9)
Receiving
(2)
Data to Information flow is as if raw material to production flow.
Chapter 1 & 2
© Prentice Hall
5
The evolution of product flow and
information flow
raw
materials
production
finished
goods
Input
data
Chapter 1 & 2
technical
support
?
Output
processing
information
© Prentice Hall
further
processing
?
6
Figure 1-1a Data in context
Context helps users understand data
Chapter 1 & 2
© Prentice Hall
7
Figure 1-1b Summarized data
Graphical displays turn data into useful
information that managers can use for
decision making and interpretation
Chapter 1 & 2
© Prentice Hall
8
Descriptions of the properties or characteristics of the
data, including data types, field sizes, allowable
values, and data context
Chapter 1 & 2
© Prentice Hall
9
Disadvantages of File Processing

Program-Data Dependence


Duplication of Data


No centralized control of data
Lengthy Development Times


Different systems/programs have separate copies of the same data
Limited Data Sharing


All programs maintain metadata for each file they use
Programmers must design their own file formats
Excessive Program Maintenance

80% of information systems budget
Chapter 1 & 2
© Prentice Hall
10
Figure 1-3 Old file processing systems at Pine Valley
Furniture Company
Duplicate Data
Chapter 1 & 2
© Prentice Hall
11
Problems with Program Data
Dependency





Each application programmer must maintain
his/her own data
Each application program needs to include
code for the metadata of each file
Each application program must have its own
processing routines for database operations:
reading, inserting, updating, and deleting
data
Lack of coordination and central control
Non-standard file formats
Chapter 1 & 2
© Prentice Hall
12
Problems with Data Redundancy
Waste of space to have duplicate data
 Causes more maintenance headaches
 The biggest problem:

Data changes in one file could cause
inconsistencies
 Compromises in data integrity

Chapter 1 & 2
© Prentice Hall
13
SOLUTION:
The DATABASE Approach
Central repository of shared data
 Data is managed by a controlling
agent
 Stored in a standardized, convenient
form

Requires a Database Management System (DBMS)
Chapter 1 & 2
© Prentice Hall
14
Database Management System

A software system that is used to create, maintain, and provide
controlled access to user databases
Order Filing
System
Invoicing
System
DBMS
Central database
Contains employee,
order, inventory,
pricing, and
customer data
Payroll
System
DBMS manages data resources like an operating system manages hardware resources
Chapter 1 & 2
© Prentice Hall
15
Advantages of the Database Approach










Program-data independence (PI)
Planned (minimal) data redundancy (DR)
Improved data consistency
Improved data sharing
Increased application development productivity
Enforcement of standards
Improved data quality
Improved data accessibility and responsiveness
Reduced program maintenance
Improved decision support
Chapter 1 & 2
© Prentice Hall
16
Costs and Risks of the Database
Approach





New, specialized personnel
Installation and management cost and
complexity
Conversion costs
Need for explicit backup and recovery
Organizational conflict
Chapter 1 & 2
© Prentice Hall
17
Figure 2-9 Three-tiered client/server database architecture
Presentation tier
Business logic tier
Data tier
Chapter 1 & 2
© Prentice Hall
18
Evolution of DB Systems
Chapter 1 & 2
© Prentice Hall
19
Chapter 2:
The Database Development
Process
© Prentice Hall
20
Objectives









Definition of terms
Describe system development life cycle
Explain prototyping approach
Explain roles of individuals
Explain three-schema approach
Explain role of packaged data models
Explain three-tiered architectures
Explain scope of database design projects
Draw simple data models
Chapter 1 & 2
© Prentice Hall
21
Information Systems Architecture
(ISA)


Conceptual blueprint for organization’s desired
information systems structure
Consists of (6Ws):
How






Processes–data flow diagrams, process decomposition,
etc. (DFD- Data Flow Diagram)
Data (e.g. Enterprise Data Model–ER Diagram) What
Data Network–topology diagram (like Fig 1-9)Where
People–people management using project Who
management tools (Gantt charts, etc.)
Events and points in time (when processes are When
performed. Use case diagram)
Reasons for events and rules (e.g., decision tables) Why
Chapter 1 & 2
© Prentice Hall
22
Data Flow Diagrams


Data flow diagrams (DFDs) are graphical
aids that describe an information system
Advantages:



freedom from committing to the technical
implementation of the system too early.
Further understanding the interrelatedness
of systems and subsystems.
communicating current system knowledge
to users .
Chapter 1 & 2
© Prentice Hall
23
Data Flow Diagrams

Data flow diagram symbols

Four basic symbols

Process

Data flow

Data store

External entity
Chapter 1 & 2
© Prentice Hall
24
Process
External entities
Chapter 1 & 2
Data flows
© Prentice Hall
25
Data store
Chapter 1 & 2
© Prentice Hall
26
Chapter 1 & 2
© Prentice Hall
27
Chapter 1 & 2
© Prentice Hall
28
Figure 2-2 Example of process decomposition of an
order fulfillment function (Pine Valley Furniture)
Decomposition = breaking
large tasks into smaller tasks
in a hierarchical structure
chart
Order form
Chapter 1 & 2
Credit status
© Prentice Hall
29
Information Systems Architecture
(ISA)


Conceptual blueprint for organization’s desired
information systems structure
Consists of (6Ws):
How






Processes–data flow diagrams, process decomposition,
etc. (DFD- Data Flow Diagram)
Data (e.g. Enterprise Data Model–ER Diagram) What
Data Network–topology diagram (like Fig 1-9)Where
People–people management using project Who
management tools (Gantt charts, etc.)
Events and points in time (when processes are When
performed. Use case diagram)
Reasons for events and rules (e.g., decision tables) Why
Chapter 1 & 2
© Prentice Hall
30
Develop Enterprise Model
Process: Data flow diagram (DFD)
Functional decomposition

Iterative process breaking
system description into finer and finer detail

Data: Entity Relationship diagram (ER Diagram)

Planning matrixes
Describe interrelationships
between planning objects
Chapter 1 & 2
© Prentice Hall
31
Data Dictionary
Data
Element (field)
Data
Entity (table)
Data
Entity (table)
Program
Modules
Chapter 1 & 2
© Prentice Hall
Data Modeling
using ERD
32
Higher
priority
Example business function-todata entity matrix (Fig. 2-3)
Chapter 1 & 2
© Prentice Hall
Spot
missing
entity
33
Planning Matrixes


Describe relationships between planning
objects in the organization
Types of matrixes:






Function-to-data entity
Location-to-function
Unit-to-function
IS-to-data entity
Supporting function-to-data entity
IS-to-business objective
Chapter 1 & 2
© Prentice Hall
34
Database Schema

Conceptual Schema


External Schema




E-R models–covered in Chapters 3 and 4
User Views: schema for different users
Subsets of Conceptual Schema
Can be determined from business-function/data
entity matrices
Physical Schema (Internal Schema)

Physical structures–covered in Chapters 5 and 6
Chapter 1 & 2
© Prentice Hall
35
Figure 2-7 Three-schema architecture
Different people
have different
views of the
database…these
are the external
schema
The internal
schema is the
underlying
design and
implementation
Chapter 1 & 2
© Prentice Hall
36
Figure 2-8 Developing the three-tiered architecture
Chapter 1 & 2
© Prentice Hall
37
Information Engineering


Top-down planning–a generic IS planning
methodology for obtaining a broad
understanding of the IS needed by the entire
organization
Four steps to Top-Down planning:




Planning
Analysis
Design
Implementation
Chapter 1 & 2
© Prentice Hall
38
Two Approaches to Database
and IS Development

SDLC





System Development Life Cycle
Detailed, well-planned development process
Time-consuming, but comprehensive
Long development cycle
Prototyping




Rapid application development (RAD)
Cursory attempt at conceptual data modeling
Define database during development of initial
prototype
Repeat implementation and maintenance activities
with new prototype versions
Chapter 1 & 2
© Prentice Hall
39
Systems Development Life Cycle
(see also Figures 2.4, 2.5)
Planning
Analysis
Logical Design
Physical Design
Implementation
Maintenance
Chapter 1 & 2
© Prentice Hall
40
Systems Development Life Cycle
 Systems planning
 Purpose – identify problem’s nature/scope
 Systems request – begins the process &
describes desired changes/improvements
 Systems planning – includes preliminary
investigation or feasibility study
 End product – preliminary investigation report
Chapter 1 & 2
© Prentice Hall
41
Systems Development Life Cycle
 Systems analysis
 Purpose is to learn exactly how the current
system operates or determine what systems
should do.
 Fact-finding or requirements determination is
used to define all functions of the current
system
Chapter 1 & 2
© Prentice Hall
42
Systems Development Life Cycle
 Options
 Develop a system in-house
 Purchase a commercial package
 Modify an existing system
 Stop development
 The end product for this phase is the systems
requirements document
Chapter 1 & 2
© Prentice Hall
43
Systems Development Life Cycle
 Systems design
 Purpose is to satisfy all documented requirements
 identify what and how the system must do.
 Identify all outputs, inputs, files, manual procedures, &
application programs
 user interface design, files organization and database
design
 Avoid misunderstanding through manager and user
involvement
 End product is system design specification
Chapter 1 & 2
© Prentice Hall
44
Systems Development Life Cycle
 Systems implementation
Construct/deliver information system
Prepares functioning, documented system
Write, test, document application programs
User and manager approval obtained
File conversion occurs
Users, managers, IS staff trained to operate and
support the system
Post-implementation evaluation performed
Chapter 1 & 2
© Prentice Hall
45
Prototyping Database Methodology
(Figure 2.6)
Chapter 1 & 2
© Prentice Hall
46
Prototyping Database Methodology
(Figure 2.6) (cont.)
Chapter 1 & 2
© Prentice Hall
47
Prototyping Database Methodology
(Figure 2.6) (cont.)
Chapter 1 & 2
© Prentice Hall
48
Prototyping Database Methodology
(Figure 2.6) (cont.)
Chapter 1 & 2
© Prentice Hall
49
Prototyping Database Methodology
(Figure 2.6) (cont.)
Chapter 1 & 2
© Prentice Hall
50
CASE


Computer-Aided Software Engineering
(CASE)–software tools providing automated
support for systems development
Three database features:



Data modeling–drawing entity-relationship
diagrams
Code generation–SQL code for table creation
Repositories–knowledge base of enterprise
information
Chapter 1 & 2
© Prentice Hall
51
Managing Projects: People Involved









Business analysts
Systems analysts
Database analysts and data modelers
Users
Programmers
Database architects
Data administrators
Project managers
Other technical experts
Chapter 1 & 2
© Prentice Hall
52
Figure 1-5 Components of the Database Environment
Chapter 1 & 2
© Prentice Hall
53