0% found this document useful (0 votes)
44 views49 pages

10e - PP - ch01 DB Environment and Development Process

The document discusses the database environment and development process. It defines key terms like database, data, and metadata. It explains the limitations of conventional file processing like program-data dependence and data redundancy. The advantages of databases include improved data sharing and consistency. Developing a database requires costs and risks related to new personnel, installation, and conversion. The database approach involves elements like data modeling, entities, and relationships. It also describes the components of the database environment and categories of database applications.

Uploaded by

Ksatria AFK
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
Download as pptx, pdf, or txt
0% found this document useful (0 votes)
44 views49 pages

10e - PP - ch01 DB Environment and Development Process

The document discusses the database environment and development process. It defines key terms like database, data, and metadata. It explains the limitations of conventional file processing like program-data dependence and data redundancy. The advantages of databases include improved data sharing and consistency. Developing a database requires costs and risks related to new personnel, installation, and conversion. The database approach involves elements like data modeling, entities, and relationships. It also describes the components of the database environment and categories of database applications.

Uploaded by

Ksatria AFK
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1/ 49

Chapter 1:

The Database Environment


and Development Process
Modern Database Management
10th Edition
Jeffrey A. Hoffer, V. Ramesh,
Heikki Topi

Focus:
Slides 15-23, 30-46
© 2011 Pearson Education, Inc.  Publishing as Prentice Hall 1
Objectives
 Define terms
 Name limitations of conventional file processing
 Explain advantages of databases
 Identify costs and risks of databases
 List components of database environment
 Identify categories of database applications
 Describe database system development life cycle
 Explain prototyping and agile development approaches
 Explain roles of individuals
 Explain the three-schema architecture for databases

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 2


Definitions
 Database: organized collection of logically
related data
 Data: stored representations of meaningful
objects and events
 Structured: numbers, text, dates
 Unstructured: images, video, documents
 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 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 3
Figure 1-1a Data in context

Context helps users understand data

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 4


Figure 1-1b Summarized data

Graphical displays turn data into useful


information that managers can use for
decision making and interpretation
Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 5
Descriptions of the properties or characteristics of the
data, including data types, field sizes, allowable
values, and data context

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 6


Disadvantages of File Processing
 Program-Data Dependence
 All programs maintain metadata for each file they use
 Duplication of Data
 Different systems/programs have separate copies of the same data
 Limited Data Sharing
 No centralized control of data
 Lengthy Development Times
 Programmers must design their own file formats
 Excessive Program Maintenance
 80% of information systems budget

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 7


Problems with 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 reading, inserting,
updating, and deleting data
 Lack of coordination and central control
 Non-standard file formats

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 8


Duplicate Data

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall


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 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 10


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 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 11


Database Management

System
A software system that is used to create, maintain, and provide
controlled access to user databases

Order Filling
System

Invoicing Central database


DBMS
System
Contains employee,
order, inventory,
Payroll pricing, and
System customer data

DBMS manages data resources like an operating system manages hardware resources

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 12


Advantages of the Database Approach
 Program-data independence
 Planned data redundancy
 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

Caution about DB benefits: P.15


Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 13
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
 Conflicts on data definitions, formats and
coding, rights to update…
 Stand-alone DB: not following DB approach
Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 14
Elements of the Database Approach(PP 10-11)
 Data models
 Graphical sys capturing nature and relationship of data
 Enterprise Data Model–high-level entities and
relationships for the organization
 Project Data Model–more detailed view, matching data
structure in database or data warehouse
 Entities
 Noun, describing a person/place/object/event/concept
 Composed of attributes
 Relationships
 Verb, describing relationship Between entities
 Usually one-to-many (1:M) or many-to-many (M:N)
 Relational Databases
 Database technology involving tables (relations)
representing entities and primary/foreign keys
representing relationships
Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 15
Figure 1-3 Comparison of enterprise and project level data models
P.11
Segment of an
enterprise data model

Segment of a project-level data model

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 16


Figure 1-3(b), P.11

One customer
may place many
orders, but each
order is placed by
a single customer
 One-to-many
relationship

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 17


One order has
many order lines;
each order line is
associated with a
single order
 One-to-many
relationship

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 18


One product can
be in many
order lines, each
order line refers
to a single
product
 One-to-many
relationship

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 19


Therefore, one
order involves
many products
and one product is
involved in many
orders

 Many-to-many
relationship

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 20


Figure 1-4, P.12

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 21


Figure 1-5 Components of the Database Environment (P.16)

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 22


Components of the
Database Environment
 CASE Tools–computer-aided software engineering
 Repository–centralized storehouse of metadata
 Database Management System (DBMS) –software
for managing the database
 Database–storehouse of the data
 Application Programs–software using the data
 User Interface–text and graphical displays to users
 Data/Database Administrators–personnel
responsible for maintaining the database
 System Developers–personnel responsible for
designing databases and software
 End Users–people who use the applications and
databases
Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 23
The Range of Database Applications

 Personal databases
 Two-tier Client/Server databases
 Multitier Client/Server databases
 Enterprise applications
 Enterprise resource planning (ERP) systems
 Data warehousing implementations

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 24


Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 25
Figure 1-6 Two-tier database with local
area network

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 26


Figure 1-7 Three-tiered client/server database
architecture

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 27


Enterprise Database Applications
 Enterprise Resource Planning (ERP)
 Integrate all enterprise functions
(manufacturing, finance, sales, marketing,
inventory, accounting, human resources)
 Data Warehouse
 Integrated decision support system derived
from various operational databases
 Compare: 1, time; 2, main purpose

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 28


Figure 1-8a Evolution of database technologies

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 29


Enterprise Data Model
 First step in database development
 Specifies scope and general content
 Overall picture of organizational data at high
level of abstraction
 Entity-relationship diagram
 Descriptions of entity types
 Relationships between entities
 Business rules

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 30


FIGURE 1-9 Example business function-to-data entity matrix

Can use this matrix to help with your DB project:


Chapter 1 © 2011 “Did
Pearson Education,
I get the rightInc.  Publishing
entities for myasbiz
Prentice Hall
functions?” 31
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 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 32
Systems Development Life Cycle
(see also Figure 1-10)
Planning

Analysis

Logical Design

Physical Design

Implementation

Maintenance

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 33


Systems Development Life Cycle
(see also Figure 1-10) (cont.)
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

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 34


Systems Development Life Cycle
(see also Figure 1-10) (cont.)
Purpose–thorough requirements analysis
Planning and structuring
Deliverable–functional system specifications
Analysis
Analysis

Logical Design

Physical Design

Database activity–thorough Implementation


and integrated conceptual
data modeling
Maintenance

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 35


Systems Development Life Cycle
(see also Figure 1-10) (cont.)
Purpose–information requirements elicitation
Planning and structure
Deliverable–detailed design specifications
Analysis

Logical
Logical Design
Design

Physical Design

Database activity– Implementation


logical database design
(transactions, forms,
Maintenance
displays, views, data
integrity and security)
Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 36
Systems Development Life Cycle
(see also Figure 1-10) (cont.)
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)
Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 37
Systems Development Life Cycle
(see also Figure 1-10) (cont.)
Purpose–programming, testing,
Planning training, installation, documenting

Analysis Deliverable–operational programs,


documentation, training materials

Logical Design

Physical Design

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

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 38


Systems Development Life Cycle
(see also Figure 1-10) (cont.)
Purpose–monitor, repair, enhance
Planning

Deliverable–periodic audits
Analysis

Logical Design

Physical Design

Database activity–
database maintenance, Implementation
performance analysis
and tuning, error Maintenance
Maintenance
corrections

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 39


Prototyping Database Methodology(Figure 1-11)

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 40


Prototyping Database Methodology
(Figure 1-11) (cont.)

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 41


Prototyping Database Methodology
(Figure 1-11) (cont.)

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 42


Prototyping Database Methodology
(Figure 1-11) (cont.)

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 43


Prototyping Database Methodology
(Figure 1-11) (cont.)

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 44


Database Schema
 External Schema
 User Views
 Subsets of Conceptual Schema
 Can be determined from business-function/data entity
matrices
 DBA determines schema for different users
 Conceptual Schema
 E-R models–covered in Chapters 2 and 3
 Internal Schema
 Logical structures–covered in Chapter 4
 Physical structures–covered in Chapter 5

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 45


Figure 1-12 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 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 46


Managing Projects
 Project–a planned undertaking of related
activities to reach an objective that has a
beginning and an end
 Involves use of review points for:
 Validation of satisfactory progress
 Step back from detail to overall view
 Renew commitment of stakeholders
 Incremental commitment–review of
systems development project after each
development phase with rejustification
after each phase
Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 47
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 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 48


FIGURE 1-13 Computer
System for Pine Valley
Furniture Company

Chapter 1 © 2011 Pearson Education, Inc.  Publishing as Prentice Hall 49

You might also like