Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

DataBase Development and Implementation Lec10 - DB Application Development, Study notes of Database Management Systems (DBMS)

Detail Summery about Database application lifecycle, DB Application Development, Application Development, Software Depression /2, Information System, Software Depression /3.

Typology: Study notes

2010/2011

Uploaded on 09/08/2011

rossi46
rossi46 🇬🇧

4.5

(10)

313 documents

1 / 8

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
DBDI 30/05/2007
Lecture_10 / AppDev
DBDI/ Lecture 10
DB Application
Development
Dr. Ala Al-Zobaidie
The slides are based on the textbook Database Systems by Connolly & Begg
30/05/2007 DBDI / AppDev 2
Lecture's Objectives
Main components of an information
system.
Database application lifecycle.
Application Development.
Transaction & User Interface Design
Forms & Reports
30/05/2007 DBDI / AppDev 3
Software Depression /1
Last few decades have seen
proliferation of software applications,
many requiring constant maintenance
involving:
correcting faults
implementing new user requirements
modifying software to run on new or upgraded
platforms
Effort spent on maintenance began to
absorb resources at an alarming rate.
30/05/2007 DBDI / AppDev 4
Software Depression /2
As a result, many major software projects
were
late
over budget
unreliable
difficult to maintain
performed poorly.
In late 1960s, led to ‘software crisis’, now
refer to as the ‘software depression’.
30/05/2007 DBDI / AppDev 5
Software Depression /3
Major reasons for failure of software projects
includes:
- lack of a complete requirements specification
- lack of appropriate development methodology
- poor decomposition of design into manageable
components.
Structured approach to development was proposed
called information systems lifecycle.
30/05/2007 DBDI / AppDev 6
Information System
Info Sys Def:
Resources that enable collection,
management, control, and
dissemination of information
throughout an organization.
Database is fundamental component of
I.S., and its development/usage should
be viewed from perspective of the wider
requirements of the organization.
pf3
pf4
pf5
pf8

Partial preview of the text

Download DataBase Development and Implementation Lec10 - DB Application Development and more Study notes Database Management Systems (DBMS) in PDF only on Docsity!

DBDI/ Lecture 10

DB Application

Development

Dr. Ala Al-Zobaidie

The slides are based on the textbook Database Systems by Connolly & Begg

30/05/2007 DBDI / AppDev 2

Lecture's Objectives

  • Main components of an information

system.

  • Database application lifecycle.
    • Application Development.
    • Transaction & User Interface Design
      • Forms & Reports

30/05/2007 DBDI / AppDev 3

Software Depression /

  • Last few decades have seen

proliferation of software applications,

many requiring constant maintenance

involving:

  • correcting faults
  • implementing new user requirements
  • modifying software to run on new or upgraded

platforms

  • Effort spent on maintenance began to

absorb resources at an alarming rate.

30/05/2007 DBDI / AppDev 4

Software Depression /

  • As a result, many major software projects

were

  • late
  • over budget
  • unreliable
  • difficult to maintain
  • performed poorly.
  • In late 1960s, led to ‘software crisis’, now

refer to as the ‘software depression’.

Software Depression /

  • Major reasons for failure of software projects

includes:

  • lack of a complete requirements specification
  • lack of appropriate development methodology
  • poor decomposition of design into manageable

components.

  • Structured approach to development was proposed

called information systems lifecycle.

Information System

  • Info Sys Def:
    • Resources that enable collection,

management, control, and

dissemination of information

throughout an organization.

  • Database is fundamental component of

I.S., and its development/usage should

be viewed from perspective of the wider

requirements of the organization.

30/05/2007 DBDI / AppDev 7

Stages of the Database System

Development Lifecycle

  • Database planning
  • System definition
  • Requirements collection and

analysis

  • Database design
  • DBMS selection (optional)
  • Application design
  • Prototyping (optional)
  • Implementation
  • Data conversion & loading
  • Testing
  • Operational maintenance.

1 2 3 4 5 7

6

8

9

10

11

30/05/2007 DBDI / AppDev 8

1. Database Planning – Mission

Statement (MS)

  • MS ∫ with overall IS strategy of the

organization.

  • MS for the DB project defines major aims of

DB application.

  • Once MS defined then mission objectives are

defined.

  • Objectives must be supported by DB project.
  • DB planning should include development of

standard for data collection, formatting,

documentation, design and implementation

30/05/2007 DBDI / AppDev 9

2. System Definition - Describes scope and boundaries of

database application and the major user

views.

  • User view defines what is required of a

database application from perspective of:

  • a particular job role (such as Manager or

Supervisor) or

  • enterprise application area (such as

marketing, personnel, or stock control).

30/05/2007 DBDI / AppDev 10

System Definition/cont.: DB application

with multiple user views

  • Database application may have one or more user views.
  • Identifying user views helps ensure that no major users of the database are forgotten when developing requirements for new application.
  • User views also help in development of complex database application allowing requirements to be broken down into manageable pieces. 3. Requirements Collection & Analysis
  • Information is gathered for each major

user view including:

  • a description of data used or generated
  • details of how data is to be

used/generated

  • any additional requirements for new

database application.

  • Information is analyzed to identify

requirements to be included in new

database application.

3. Requirements Collection &

Analysis/cont.

  • Another important activity is deciding

how to manage database application

with multiple user views.

  • Three main approaches:
    • centralized approach
    • view integration approach
    • combination of both approaches.

30/05/2007 DBDI / AppDev 19

4. Conceptual DBD/Cont.

• Two possible approaches:

1. Describing the transactions

– Check that all the information required

by each transaction is provided by the

model, by documenting a description of

each transaction’s requirements.

2. Using transaction pathways

– Checking involves diagrammatically

representing the pathway taken by

each transaction directly on the ER

diagram. 30/05/2007^ DBDI / AppDev^20

4. Conceptual DBD/Cont./Describing

the transactions

‹ Extract from data dictionary for Staff user views

of DreamHome showing description of entities

List the details of properties managed by a named member of staff at the branch.

30/05/2007 DBDI / AppDev 21

4. Conceptual DBD/Cont./ Using

pathways approach

(a) List details of staff

supervised by a named

Supervisor at the branch

(b) List details of

Assistants,

alphabetically by name

at the branch.

(c)…

(d) List the details of

properties managed by

a named member of

staff at the branch.

30/05/2007 DBDI / AppDev 22

4. Logical DBD/Cont

• Step 2 Build and validate logical data model

  • Step 2.1 Derive relations for logical data model (mapping steps)
  • Step 2.2 Validate relations using normalization
  • Step 2.3 Validate relations against user transactions
  • Step 2.4 Define integrity constraints
  • Step 2.5 Review logical data model with user
  • Step 2.6 Merge logical data models into global model (optional step)
  • Step 2.7 Check for future growth

4. Physical DBD/Cont

• Step 3

– Translate logical data model for

target DBMS

• Step 3.1 Design base relations

• Step 3.2 Design representation of derived

data

• Step 3.3 Design general constraints

4. Physical DBD/Cont

• Step 4 Design file organizations & indexes

  • Step 4.1 Analyze transactions
    • transactions frequency & performance impact
    • transactions that are critical to the business;
    • Identifying peak load.
    • need to know high-level functionality of the transactions, such as:
      • attributes that are updated;
      • search criteria used in a query.
  • To help identify these can use:
    • transaction/relation cross-reference matrix , showing relations that each transaction accesses, and/or
    • transaction usage map , indicating which relations are potentially heavily used.

30/05/2007 DBDI / AppDev 25

4. Physical DBD/Cont/ Step 4.

Analyze transactions

  • To focus on areas that may be

problematic:

(1) Map all transaction paths to relations.

(2) Determine which relations are most frequently

accessed by transactions.

(3) Analyze the data usage of selected

transactions that involve these relations.

30/05/2007 DBDI / AppDev 26

4. Physical DBD/Cont./

characteristics of Transactions

  • Important characteristics of transactions:
    • 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.

30/05/2007 DBDI / AppDev 27

4. Physical DBD/Cont/ Step 4.

Analyze transactions

Cross-referencing transactions and relations

30/05/2007 DBDI / AppDev 28

4. Physical DBD/Cont/ Step 4.1 Analyze

transactions : Example Transaction Usage

Map

4. Physical DBD/Cont Design file

organizations & indexes

‹ Step 4.2 Choose file organizations

  • Heap, Hash, Indexed Sequential Access Method

(ISAM), B+-Tree, and Clusters

‹ Step 4.3 Choose indexes

  • A primary or clustering index?
  • Will secondary indexes improve the performance of

the system?

  • balance overhead of maintenance & use of secondary

indexes against gained performance.

  • Guidelines for choosing indexes

‹ Step 4.4 Estimate disk space requirements

4. Physical DBD/Cont - Step 5 Design user views - Step 6 Design security mechanisms - Step 7 Consider the introduction of

controlled redundancy (de-normalization)

  • Step 8 Monitor and tune the operational

system

30/05/2007 DBDI / AppDev 37

GUI :Criteria for good design \

  • Consistent
    • Applications should be internally consistent in their look & feel
    • Involves bringing users to consensus on terms
  • Clarity
    • Use real-world language & eliminating cryptic commands, mnemonics & codes
  • Aesthetics
    • Should be visually pleasing
    • Let the eye focus on the most important information
    • Studies on fixation & eye movement show that most most people look as in this pattern - But, is it true for every culture?
    • Spatial grouping & judicious use of lines & borders can separate windows into sensible blocks

30/05/2007 DBDI / AppDev 38

GUI :Criteria for good design \

  • Forgiveness
    • Provide polite & informative feedback
    • Exploration is encouraged by making the system

forgiving

  • Always give your user a way to abandon his work if

he hasn’t explicitly saved it “

  • Awareness of human strengths & limitations
    • Easier to recognize visual clues than memorizing

them “Recognition is easier than Recall”

  • Context-sensitive help, effective use of status bar, etc.
  • Human hrair limit: somewhere around 7, + or − 2

30/05/2007 DBDI / AppDev 39

GUI :Criteria for good design \

  • Designing your screens:
    • Number of events managed by a widow affects both the:
      • User’s ability to understand the interface, &
      • Programmer’s ability to maintain the window as the

system is enhanced

  • How to measure it? What is the level of window cohesion?
    • Rate the aggregation of events on windows. How?
  • There are many ways in which we can group

objects/functions in one screen or a set of related

screens.

  • We are only covering the main three types of window

cohesion

30/05/2007 DBDI / AppDev 40

GUI :Criteria for good design \

  • Functional cohesion
    • Limits the window to managing one business level event
  • Sequential cohesion
    • Groups predecessor/successor events together on a window
  • Communicational cohesion
    • Groups events together which communicate with the same object
  • Others
    • Procedural cohesion
    • Temporal cohesion
    • Logical cohesion
    • etc.

*GUI :Criteria for good design summary *

Most windows of well-designed business application tend

to fall into the top three levels of cohesion

Functional

  • Yields most reusable, understandable & maintainable windows of all, but
  • Would result in far too many windows if used exclusively

Sequential

  • Excellent method for designing windows where the user executed a series of tasks on a regular basis

Communicational

  • Does a good job of keeping data access & visually apparent business rules corralled in one place, but
  • Increases the complexity of managing enablement & disablement on the interface

Determine what items will be included in the report

  • Requirements analysis
  • Data dictionary

Sketch a print layout

Determine

  • length of data items
  • number of decimal places
  • Font size
  • Etc…

Planning a Report

30/05/2007 DBDI / AppDev 43

Reports usually consist of:

Headings

Title

Page Number / Date

Data from a master record

Column Headings

Data and details

Repeating data items grouped according to the data in the

heading - data from child records

Derived / calculated data

Footers / Summaries

Column totals / subtotals

Report’s Contents

30/05/2007 DBDI / AppDev 44

For each Customer record, show:

  • Name of customer
  • Address of a customer
  • Total orders taken
  • Total value of orders taken
  • Total number of items ordered
  • Average value of items ordered For each order taken show:
  • Order date
  • Value of order
  • Number of items ordered
  • Average value of items ordered

Report Specification

Customer

Order

1

N

Make

30/05/2007 DBDI / AppDev 45

Wednesday, 30 May 2007

Order Breakdown

Customer Mr Buy AllTime Team North

Date Order Value No. Of Items Average Value 07-Nov-2001 £29.50 1 £29. 15-Oct-2001 £88.50 2 £44.

Totals Order Value No. Of Items Average Value £118.00 3 £39.

Page 1 of 1

Example

30/05/2007 DBDI / AppDev 46

Report Guidelines

‹ Page breaks can be forced - typically on a change of

master record

‹ A ‘launch’ screen can set criteria for the report (e.g. in the

lab report tutorial

‹ Reports and documents should be designed to be read

from left to right and top to bottom

‹ The most important items should be the easiest to find

‹ All pages should have a title and page number and show

the date the output was prepared

‹ All columns should be labeled

‹ Abbreviations should be avoided

30/05/2007 DBDI / AppDev 47

Summary

  • Components of an IS
  • Software Depression
  • Database System Development Lifecycle
    • Application design
      • Transaction Design
      • User Interface Guidelines