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
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
