Chapter 9
-
Upload
databaseguys -
Category
Documents
-
view
432 -
download
0
Transcript of Chapter 9
Chapter 9
Database Planning, Design,
and Administration
Transparencies
22
Chapter 9 - Objectives
The main stages of the information systems lifecycle.
The relationship between the database application and information systems lifecycles.
The main stages of the database application lifecycle.
3
Chapter 9 - Objectives
The main phases of database design: conceptual, logical, and physical design.
The benefits of Computer-Aided Software Engineering (CASE) tools.
The types of criteria used to evaluate a DBMS.
4
Chapter 9 - Objectives
How to evaluate and select a DBMS.
The distinction between data administration and database administration.
The purpose and tasks associated with data administration and database administration.
5
Software Crisis
Last few decades have seen the proliferation of software applications.
Many applications required constant maintenance involving– correcting faults– implementing new user requirements– modifying the software to run on new or
upgraded platforms
6
Software Crisis
As a result, many major software projects were – late– over budget– unreliable– difficult to maintain– performed poorly
Also called software depression.
7
Software Crisis
Study on software projects in 1996 in the UK» 80 - 90% do not meet their performance goals.
» About 80% of systems are delivered late and over budget.
» Around 40% of developments fail or are abandoned.
» Under 40% fully address training and skills requirements.
» Less than 25% properly integrate business and technology objectives.
» Just 10 - 20% meet all their success criteria.
8
Software Development Lifecycle
Major reasons for failure of software projects– lack of complete requirements specification– lack of appropriate development methodology– poor decomposition of design into manageable
components
Solution - a structured approach to development of software called Information System Development Lifecycle.
9
Information System (IS) Resources that enable the collection, management, control,
and dissemination of information throughout an organization.
Components of IS include– Database– Database software– Application software– Computer hardware including storage media– Personnel using and developing the system
10
Information System Development Lifecycle
Database is a fundamental component of an IS.
IS lifecycle is linked to the lifecycle of the database system that supports it.
Stages include: planning, requirements collection and analysis, design (including database design), prototyping, implementation, testing, conversion, and operational maintenance.
11
Database Application Lifecycle
12
Database Application Lifecycle
Database planning System definition Requirements collection and analysis Database design DBMS selection (optional)
13
Database Application Lifecycle
Application design Prototyping (optional) Implementation Data conversion and loading Testing Operational maintenance
14
Database Planning
The management activities that allow the stages of the database application to be realized as efficiently and effectively, as possible.
Identifies work to be done; the resources with which to do it; and the money to pay for it all.
Integrated with the overall IS strategy of the organization.
15
Example - Corporate Data Model
16
System Definition
The scope and boundaries of the database application including its major application areas and user groups.
17
Requirements Collection and Analysis
The process of collecting and analyzing information about the part of the organization that is to be supported by the database application, and using this information to identify the users’ requirements of the new system.
18
Database Design
The process of creating a design for a database that will support the enterprise’s operations and objectives.
19
Database Design
Major aims– Represent data and relationships between data
required by all major application areas and user groups.
– Provide data model that supports any transactions required on the data.
– Specify a minimal design that is appropriately structured to achieve the stated performance requirements for the system such as response times.
21
DBMS Selection
The selection of an appropriate DBMS to support the database application.
Undertaken at any time prior to logical design provided sufficient information is available regarding system requirements.
22
Application Design
The design of the user interface and the application programs that use and process the database.
Database and application design are parallel activities.
23
Prototyping
Building a working model of a database application.
Purpose– To identify features of a system that work well, or
are inadequate– To suggest improvements or even new features– To clarify the users’ requirements – To evaluate the feasibility of a particular system
design.
24
Prototype Development Method Stages
System Development Approach
Understanding the system requirements before design is critical to the success of creating today’s complex system.
A system development approach based on modeling and prototyping
has proven very effective in understanding the system requirements.
Modeling and rapid prototyping approach replaces the traditional waterfall approach.
Two Pronged approach to Building A System –Modeling and Prototyping
Modeling:
Purposes: To present the essential characteristics of the System.
Characteristics: Model is created based on observation of the real world or approximation based on system goals. (a simplified representation of a complex reality)
Approach: Models are used to segment a complex system into successively simpler components that can be easily understood.
Two Pronged approach to Building A System –Modeling and Prototyping
Prototyping: Purposes: To validate and refine the model of a system.
Characteristics: Prototyping is a discipline of interactive experimentation to stimulate user feedback.
Approach: A prototype is a materialization of modeling process by building rapidly and simulating the essential aspects of the system.
Types of Prototyping
Evaluative (mock-up) prototyping (Blue print approach) Use: Visualization; demonstration; inspection
Advantages. Reduce risk; low cost; resolve uncertainty Early; fast; flexible
How: Focuses on a relatively small number of questions to avoid becoming too complex.
Generally thought of a throw-away.
Types of Prototyping
Straw man (exploratory) prototyping (scale model approach)
Use: Experiment; validating and refining the conceptual as well as logical data model.
Advantages. Used to improve design; discover things about a proposed system that would otherwise not be revealed.
How: Evaluate the impact on work flows; validate ease of use.
Types of Prototyping
Evolution prototyping (real world model)
Use: Production use.
Advantages. Part of production exercise.
How: Explore functionality of subsystem and system; probe technical feasibility the performance and the integrity of the system.
Stages of Prototyping
Planning
Initial analysis and design
Construction
Tryout
Evaluation
Disposal
Dimensions of Prototyping
Relationships of any prototyping to its eventual system are characterized along four dimensions:
Focus – for example, a prototype may focus on the functionality, user interface, system integration, reliability, and performance.
Scope– Is a measure of how much of the eventual system the prototype represents.
Dimensions of Prototyping
Depth – is a measure of how deeply it represents the behavior of the eventual system. For ex., a shallow prototype of a message system might display ‘canned’ messages, where a deeper prototype might actually perform communications to provide a more realistic surrogate for the eventual system.
Scale– Is a measure of how its size or performance compares with that of the eventual system.
25
Implementation
The physical realization of the database and application designs.– Use DDL of DBMS to create database schemas and
empty database files.– Use DDL to create any specified user views.– Use 3GL or 4GL to create application programs.
Parts of these programs are the database transactions, created using DML of DBMS possibly embedded in a host programming language.
26
Data Conversion and Loading
Transferring any existing data into the new database and converting any existing applications to run on the new database.– Only required when a new database system is
replacing an old system. – DBMS normally have a utility that loads existing files
into the new database. – Where applicable, it may be possible to convert and
use application programs from the old system for use by the new system.
27
Testing
The process of executing the application programs with the intent of finding errors.– Use carefully planned test strategies and realistic
data. – Testing cannot show the absence of faults; it can
show only that software faults are present.– Demonstrates that database and application
programs appear to be working according to requirements.
28
Operational Maintenance
The process of monitoring and maintaining the system following installation.– Monitoring the performance of the system. – If performance falls, may require tuning or
reorganization of the database.– Maintaining and upgrading the database
application (when required). – Incorporating new requirements into the
database application.
29
Overview of Database Design Main aims of data modeling
– To assist in the understanding of the meaning (semantics) of the data.
– To facilitate communication about requirements.
A data model facilitates understanding – Each user’s perspective of the data.– Nature of data itself, independent of physical
representations.– The use of data across applications.
30
Overview of Database Design - Criteria for Data Model
31
Conceptual Database Design
The process of constructing a model of the information used in an enterprise, independent of all physical considerations.– Data model is built using the information in
users’ requirements specification. – Source of information for the logical design
phase.
32
Logical Database Design
The process of constructing a model of the information used in an enterprise based on a specific data model (e.g. relational), but independent of a particular DBMS and other physical considerations.
The conceptual data model is refined and mapped on to a logical data model.
33
Database Design
A logical model that represents multiple user views of an organization is called a global logical data model.
There are two major approaches to merging user views.– Centralized– View integration
34
Database Design - Merging User Views
Centralized approach– Merge separate user requirements that represent
distinct user views into a single set of user requirements, and then build the global logical data model.
View integration approach– Merge separate local logical data models that
represent distinct user views into one global logical data model.
35
Physical Database Design
The process of producing a description of the implementation of the database on secondary storage.
Describes the storage structures and access methods used to achieve efficient access to the data.
Tailored to a specific DBMS system.
36
ANSI-SPARC Architecture and Database Design Phases
37
Application Design
Includes two important activities– Transaction design– User interface design
38
Application Design - Transaction Design
Transaction– An action or series of actions, carried out by
a single user or application program, which accesses or changes the content of the database.
Purpose to define and document the high-level characteristics of the transactions required on the database system.
39
Application Design - Transaction Design Important characteristics of transactions include
– Data to be used by the transaction– Functional characteristics of the transaction– Output of the transaction– Importance to the users– Expected rate of usage
Three main types of transactions: retrieval, update and mixed.
Transaction Analysis
“A Transaction is a collection of database operations grouped into a unit of work that is either completely executed or completely abandoned”
TM (Transaction Monitors) are a class of transaction-
processing applications that were originally designed to manage very large numbers of simultaneous transactions against mainframe database mgt systems.
MTS (Microsoft Transaction Server) brings the
robustness and scalability to the client-server arena.
Transaction Analysis
Transactions can be classified as either implicit or explicit. Implicit transactions are single SQL statements that execute as an atomic unit. Explicit transactions are groupings of SQL statements surrounded by transaction delimiters: Begin Transaction, Commit Transaction, Rollback Transaction.
40
Application Design - User Interface Design Guidelines
Meaningful title Comprehensible instructions Logical grouping and sequencing of fields Visually appealing layout of the form/report Familiar field labels Consistent terminology and abbreviations Consistent use of color
41
Application Design - User Interface Design Guidelines
Visible space and boundaries for data-entry fields
Convenient cursor movement Error correction for individual characters and
entire fields Error messages for unacceptable values Optional fields marked clearly Explanatory messages for fields Completion signal
42
Computer-Aided Software Engineering (CASE) Tools
Purpose - To support the efficient and effective development of database applications.
CASE support may include– A data dictionary to store information about the database
application’s data.– Design tools to support data analysis.– Tools to develop the corporate, conceptual, and logical
data models.– Tools to enable the prototyping of applications.
43
Computer-Aided Software Engineering (CASE) Tools
Divided into three categories: upper-CASE, lower-CASE, and integrated-CASE.
Can provide the following benefits– Standards– Integration– Support for standard methods– Consistency– Automation
44
Database Application Lifecycle - CASE Tools
45
DBMS Selection
Define Terms of Reference of study
Shortlist two or three products
Evaluate products
Recommend selection and produce report
46
DBMS Evaluation Features
47
DBMS Evaluation Features
48
DBMS Evaluation Features
49
DBMS Evaluation Features
50
Example - Evaluation of DBMS Product
51
Database Application Lifecycle - DA and DBA Major and Minor Roles
52
Data Administration
The management of the data resource, which includes database planning, development and maintenance of standards, policies and procedures, and conceptual and logical database design.
53
Data Administration Tasks
54
Database Administration
The management of the physical realization of a database application, which includes physical database design and implementation, setting security and integrity controls, monitoring system performance, and reorganizing the database, as necessary.
55
Database Administration Tasks
56
DA and DBA – Main Task Differences.