Transcript A data - Computer Information Systems

The Database Environment
and Development Process
An Overview
Outline
 Basic concepts and definitions
 Benefits of Database Management
Systems (DBMS)
 A brief look at the Relational DBMS
 Types of Database Applications
 Database Development Process
Basic Concepts and Definitions
 Database
 An organized collection of logically related data
 a list of clients, or customer orders
 organized in a way that enables fast and efficient
storage, access and manipulation
 Data
 Facts that can be recorded and stored using computer
media
 traditionally this included text and numbers
 modern usage now includes objects such as sounds,
images, and video clips
Database System
 The application of technology to business processes,
gathering data and creating information that is
valuable to managers who make decisions
N. Caroline Daniels, IT: The Management Challenge
 A model of an enterprise that captures the information
structure and content which describes and
operationalizes the function of the enterprise.
Les Waguespack
Information
Data that has been processed in such a way that
it can increase the knowledge of the person who
uses it
Examples are data that has been:
 placed in a context (see next slide)
 summarized (e.g., as in a graph)
Raw Data
How to interpret this?
Metadata
Data that describes the properties or
characteristics of other data (a means of providing
context for data)
See Table 1-1
in textbook
Figure 1-1a Data in Context
……………
Even when the context is provided, large volume of facts
is difficult to analyze or make decisions based on.
Figure 1-1b Summarized data
Outline
 Basic concepts and definitions
 Benefits of Database Management
Systems (DBMS)
 A brief look at the Relational DBMS
 Types of Database Applications
 Database Development Process
Traditional File Processing
 Date back to before we had databases
 Still in use today, including backup of database
systems
Disadvantages of File Processing
 Program-Data Dependence
 All programs maintain metadata for each file they use
 Data Redundancy (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 of information systems budget
Problems with Data Redundancy
 Waste of space to have duplicate data
 Causes more maintenance headaches
 The biggest Problem:
 When data changes in one file, could
cause inconsistencies
 Compromises data integrity
Solution:
The DATABASE Approach
 Central repository of shared data
 Data is managed by a controlling agent
(DBMS)
 Stored in a standardized, convenient
form
Requires a Database Management System (DBMS)
Database Management System
Application
#1
Application
#2
Application
#3
DBMS
DBMS manages data
resources like an operating
system manages hardware
resources
Database
containing
centralized
shared data
Database Management Systems
(DBMS)
 DBMS:
 General-purpose software system which permits data to
be stored non-redundantly and facilitates the processes
of defining, creating, using and maintaining databases
 Database and Repository:
 Includes data and metadata that describes the database
data - the actual values of interest
metadata - descriptions of the characteristics of the
stored data
Data and metadata are stored in one place,
outside of the application program (decoupled from
the code).
Advantages of Database Approach
 Program-Data Independence
 Metadata stored in DBMS, so applications don’t need to
worry about data formats
 Data queries/updates managed by DBMS so programs
don’t need to process data access routines
 Results in: increased application development and
maintenance productivity
 Minimal Data Redundancy
 Leads to increased data integrity/consistency
Advantages of Database Approach
 Improved Data Sharing
 Different users get different views of the data
 Enforcement of Standards
 All data access is done in the same way
 Improved Data Quality
 Constraints, data validation rules
 Better Data Accessibility/ Responsiveness
 Use of standard data query language (SQL)
 Security, Backup/Recovery, Concurrency
 Disaster recovery is easier
Costs and Risks of the
Database Approach
 Up-front costs:
 Installation Management Cost and Complexity
 Conversion Costs
 Ongoing Costs
 Requires New, Specialized Personnel
 Need for Explicit Backup and Recovery
 Organizational Conflict
 Old habits die hard
Evolution of DB Systems







Flat files - 1960s - 1980s
Hierarchical – 1970s - 1990s
Network – 1970s - 1990s
Relational – 1980s - present
Object-oriented – 1990s - present
Object-relational – 1990s - present
Data warehousing – 1980s present
 Web-enabled – 1990s - present
Outline
 Basic concepts and definitions
 Benefits of Database Management
Systems (DBMS)
 A brief look at the Relational DBMS
 Types of Database Applications
 Database Development Process
Relational Databases Organize
Data in Tables
Field 1
Field 2
Field 3
Record 1
Record 2
Record 3
column represents a Field (a.k.a attribute,
characteristic)
 Each
 Each
tuple)
row represents a Record (a.k.a instance,
May seem simple, but…
Example: poorly designed database.
The purpose of this table is to keep track of students, their majors, advisors
and their email addresses.
ST_ID
ST_FIRST ST_LAST
ST_MAJOR
ADV_FIRST ADV_LAST ADV_EMAIL ADV_ID
001
Adam
Gopnik
Literature
William
Shakespeare
[email protected]
352
035
Sandra
Smith
Literature
James
Joyce
[email protected]
465
735
Barbara
Richards
Astronomy
Galileo
Galilei
[email protected]
773
136
Preston
Jones
Astronomy
Galileo
Galilei
[email protected]
644
001
Ryan
Cooper
Literature
William
Shakespeare
[email protected]
352
Consider what would happen when the table has to be updated to reflect the following events:
1.Sandra Smith graduates.
2.Galilei’s email has changed
3.A new professor is hired and has to be assigned an ID but has not yet been assigned any
students to advise.
The Database Design Process
 Conceptual Database Design
 Entity-Relationship Diagrams (ERDs)
 Logical Database Design
 Translate the conceptual model into files, tables, or
objects (depending on type of DBMS)
 Physical Database Design
 Lay out the actual DBMS architecture
Figure 1-3 Conceptual data model (ERD)
Figure 1-3 Segment from enterprise data model
One customer may place many
orders, but each order is placed by
a single customer
 One-to-many relationship
Figure 1-3 Segment from enterprise data model
One order has many order lines;
each order line is associated with
a single order
 One-to-many relationship
Figure 1-3 Segment from enterprise data model
One product can be in many order
lines, each order line refers to a
single product
 One-to-many relationship
Figure 1-4 Order, Order_Line, Customer, and Product tables
Relationships established in special columns (or tables) that
provide links between tables representing the entities.
Data Tables (Relations)
Relationships
Outline
 Basic concepts and definitions
 Benefits of Database Management
Systems (DBMS)
 A brief look at the Relational DBMS
 Types of Database Applications
 Database Development Process
The Range of
Database Applications
 Personal Database – standalone desktop
database
 Workgroup Database – local area network
(<25 users)
 Department Database – local area network
(25-100 users)
 Enterprise Database – wide-area network
(hundreds or thousands of users)
Components of the
Database Environment
 CASE Tools – Computer-Aided Software Engineering tools
 Database Management System (DBMS) – software for
managing the database


Database – storehouse of the data
Repository – centralized storehouse of metadata
 Application Programs – software using the data

User Interface – text and graphical displays to users
Human Resources Needed
 Systems Analysts
 Database Analysts/Designers
 Data/Database Administrators
 Programmers
Database Responsibilities
 Responsibilities
 Data planning for the
long term
 Define standards
 Conceptual and logical
design (ERDs and
LDMs)
 Physical design
 Data integrity and
working with other
departments
 Responsibilities





Data security
Database performance
Backup/recovery
Business rules
Determine user
requirements (interviewing
users)
 Design database
applications
 Program database
applications
Outline
 Basic concepts and definitions
 Benefits of Database Management
Systems (DBMS)
 A brief look at the Relational DBMS
 Types of Database Applications
 Database Development within IS
Development Process
Information Systems Architecture
“A conceptual
blueprint or plan
that expresses the
desired future
structure for the
information
systems in an
organization.”
Information Systems Architecture
 Key components:




data
processes which manipulate data
network which transports data
people who perform processes and send and
receive data
 events and points in time when processes
are performed
 reasons for events and rules which govern
data processing
Information Engineering
“An Information
Systems Architecture is
developed by IS
planners following a
particular methodology
such as Information
Engineering.”
Information Engineering
 A data-oriented methodology to create and maintain
information systems
 Uses top-down planning in which specific
information systems are deduced from a broad
understanding of organizational information needs,
rather than relying on specific user information
requests
 Offers perspective on relationship of information
systems to business objectives
Top-Down vs. Bottom-Up
Top-Down Planning:
“A methodology that
attempts to gain a
broad understanding
of the information
system needs of the
entire organization”
Bottom-Up Planning:
“A methodology that
identifies and defines IS
development projects
based upon solving
operational business
problems or taking
advantage of business
opportunities”
Information Engineering Planning
 Identify strategic
planning factors
 Goals
 Critical success
factors
 Problem areas
 Identify corporate
planning objects




Organizational units
Locations
Business functions
Entity types
 Develop enterprise
model
 Process
decomposition
 Enterprise data
model (e.g., ERD)
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
Enterprise Data Modeling
“The first step in
database development,
in which the scope and
general contents of
organizational
databases are
specified.”
Enterprise Data Model
 A model which includes:
 overall range of organizational databases
 general contents of organizational databases
 Built as part of IS planning for the
organization and not the design of a
particular database
 One part of an organization’s overall
information systems architecture (ISA)
Figure 2-1 Segment from enterprise data model (Pine
Valley Furniture Company) [simplified E-R diagram,
repeat of figure 1.3]
Enterprise data model
describes the entities in an
organization and the
relationship between these
entities
Data Entity
Types
Business
Function (users)
Business Planning
Product Development
Materials Management
Order Fulfillment
Order Shipment
Sales Summarization
Production Operations
Finance and Accounting
Customer
Product
Raw Material
Order
Work Center
Work Order
Invoice
Equipment
Employee
Example business function-to-data
entity matrix (fig. 2.3)
X
X
X
X
X X
X X
X X
X
X X
X X
X
X
X
X X X X
X
X X X X X X X
X X
X
X
X
X
X
X X X X
X X
X X X
X X X
Alternative 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.
 Especially useful for extending the IS functionality.
Systems Development Life Cycle
(SDLC) (figures 2.4, 2.5)
Project Identification
and Selection
Project Initiation
and Planning
Analysis
Logical Design
Physical Design
Implementation
Maintenance
Database development within SDLC
SDLC
Identify Project
Initiate and Plan
Analyze
Logical Design
Physical Design
Implementation
Maintenance
Database Development
Activities
Enterprise
Data Modeling
Conceptual
Data Modeling
Logical
DB Design
Physical DB
Design/Creation
DB
Implementation
DB
Maintenance
Enterprise Data Model
 First step in database development
 Specifies scope and general content
 Overall picture of organizational data,
not specific design
 Entity-relationship diagram
 Descriptions of entity types
 Relationships between entities
 Business rules
Enterprise
Modeling
Conceptual
Data Modeling
Logical
DB Design
Physical DB
Design/Creation
DB
Implementation
DB
Maintenance
Conceptual Database Modeling
 Determine user requirements
 Determine business rules
 Build conceptual data model
 outcome is an entity-relationship
diagram or similar communication
tool
Enterprise
Modeling
Conceptual
Data Modeling
Logical
DB Design
Physical DB
Design/Creation
DB
Implementation
DB
Maintenance
Logical Database Design
 Select logical database model
 Map Entity-Relationship Diagrams
 Normalize data structures
 Specify business rules
Enterprise
Modeling
Conceptual
Data Modeling
Logical
DB Design
Physical DB
Design/Creation
DB
Implementation
DB
Maintenance
Physical Database Design
 Select DBMS
 Select storage devices
 Determine access methods
 Design files and indexes
 Determine database distribution
 Specify update strategies
Enterprise
Modeling
Conceptual
Data Modeling
Logical
DB Design
Physical DB
Design/Creation
DB
Implementation
DB
Maintenance
The Prototyping Approach
Identify User Needs
R
e
v
i
s
e
Develop Prototype
Evaluate Prototype
Prototype Acceptable?
Implement Prototype