The Database Development

Process

1 © 2009 by Prentice Hall

Information Engineering
 A data-oriented methodology to create and
maintain information systems
 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 2 2
Information Systems Planning
 Purpose–align information technology with
organization’s business strategies
 Three steps:
1. Identify strategic planning factors
2. Identify corporate planning objects
3. Develop enterprise model

Chapter 2 3
Identify Strategic Planning Factors
 Organization goals –what we hope to accomplish
 Critical success factors –what MUST work in order
for us to survive
 Problem areas –weaknesses we now have

Chapter 2 4
Identify Corporate Planning Objects
 Organizational units – departments
 Organizational locations
 Business functions – groups of business
processes
 Entity types – the things we are trying to model
for the database
 Information systems – application programs

Chapter 2 5
Develop Enterprise Model
 Functional decomposition
 Iterative process breaking system description into finer and
finer detail
 Enterprise data model

 Planning matrixes
 Describe interrelationships
between planning objects

Chapter 2 6
Example of process decomposition of an order
fulfillment function (Pine Valley Furniture)

Decomposition = breaking
large tasks into smaller tasks
in a hierarchical structure
chart

7
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 2 8
 Example business function-to-
data entity matrix

Chapter 2
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 2 10
Systems Development Life Cycle
Planning

Analysis

Logical Design

Physical Design

Implementation

Maintenance

Chapter
11 2
Systems Development Life Cycle

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

Logical Design

Physical Design

Database activity– Implementation

enterprise modeling and early
conceptual data modeling Maintenance

Chapter 2 12
 Systems Development Life Cycle
Purpose–thorough requirements analysis
Planning and structuring
Deliverable–functional system specifications
Analysis
Analysis

Logical Design

Physical Design

Implementation
Database activity–Thorough
and integrated conceptual
data modeling Maintenance

Chapter 2 13
 Systems Development Life Cycle
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)
Chapter
14 2
 Systems Development Life Cycle
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
15 2
 Systems Development Life Cycle
Purpose–programming, testing, training,
Planning installation, documenting
Deliverable–operational programs,
Analysis documentation, training materials

Logical Design

Physical Design

Database activity– Implementation

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

Chapter
16 2
 Systems Development Life Cycle

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

Chapter
17 2
 Prototyping Database Methodology

18
 Prototyping Database Methodology

19
 Prototyping Database Methodology

20
 Prototyping Database Methodology

21
 Prototyping Database Methodology

22
 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 2 23
Packaged Data Models
 Model components that can be purchased,
customized, and assembled into full-scale data models
 Advantages
 Reduced development time
 Higher model quality and reliability
 Two types:
 Universal data models
 Industry-specific data models

Chapter 2 24
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 re-justification after each phase

Chapter 2 25
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 2 26
Schemas versus Instances
• Database Schema:
• The description of a database. Includes descriptions of the
database structure and the constraints that should hold on the
database.
• Schema Diagram:
• A diagrammatic display of (some aspects of) a database
schema.
• Schema Construct:
• A component of the schema or an object within the schema,
e.g., STUDENT, COURSE.
• Database Instance:
• The actual data stored in a database at a particular moment
in time. Also called database state (or occurrence).
Chapter 2 27
Database Schema Vs. Database State
• Database State:
• Refers to the content of a database at a moment in time.
• Initial Database State:
• Refers to the database when it is loaded
• Valid State:
• A state that satisfies the structure and constraints of the
database.
• Distinction
• The database schema changes very infrequently. The
database state changes every time the database is updated.
• Schema is also called intension, whereas state is called
extension.

Chapter 2 28
 Database Schema
 Internal / Physical Schema: covered in Chapters 5 and 6
 How data will be stored in DBMS
 at the internal level to describe physical storage structures and access paths.
Typically uses a physical data model
 Conceptual Schema: covered in Chapters 3 and 4
 E-R models– Single coherent definition of external views of enterprise data
 at the conceptual level to describe the structure and constraints for the whole
database for a community of users. Uses a conceptual or an implementation data
model.
 External Schema:
 User Views, Subsets of Conceptual Schema
 Can be determined from business-function/data entity matrices
 DBA determines schema for different users
 at the external level to describe the various user views. Usually uses the same data
model as the conceptual level.

Chapter 2 29
 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

30
Three-Schema Architecture
 Mappings:
 among schema levels are needed to transform requests and
data. Programs refer to an external schema, and are mapped
by the DBMS to the internal schema for execution.

Chapter 2 31
Data Independence
• Logical Data Independence:
• The capacity to change the conceptual schema without having
to change the external schemas and their application programs.
• Physical Data Independence:
• The capacity to change the internal schema without having to
change the conceptual schema.

Chapter 2 32
Data Independence
 When a schema at a lower level is changed, only the
mappings between this schema and higher-level schemas
need to be changed in a DBMS that fully supports data
independence.
 The higher-level schemas themselves are unchanged.
Hence, the application programs need not be changed
since they refer to the external schemas.

Chapter 2 33
Figure 2-8 Developing the three-tiered architecture

34
Figure 2-9 Three-tiered client/server database architecture

35
 Pine Valley Furniture

Segment of project data model (Figure 2-11)

Chapter 2 36
Figure 2-12 Four relations (Pine Valley Furniture)

Chapter 2 37
Figure 2-12 Four relations (Pine Valley Furniture) (cont.)

Chapter 2 38
 Due date : 29 – 10 – 2009
Max Group members: 3 to 4
Group Assignment –
 Option01: Consider NIIT as a unit business entity,
 Option02: Consider customer support center of a mobile
company as a business entity
 Define several functions and do a functional decomposition to at
least three levels. E.g. depts and functionality they perform
 Define several data entity types and draw a preliminary enterprise
data model
 For the assignment MUST read the pine valley furniture company
project request
 Deliverables

Functional decomposition doc – textual descriptions (point wise)
 Enterprise Data model
 Viva & discussion in the Lab

Chapter 2 39