Transcript presentation - University of Reading

Database Design
Anatomy of an application
John Wordsworth
Department of Computer Science
The University of Reading
[email protected].
Room 129, Ext 6544
April 2002
2/CS/3X
APP 1
Lecture objectives
• To review the notion of an application
• To remind ourselves about the place of
transactions in designing and application.
• To review interface design guidelines
April 2002
2/CS/3X
APP 2
What is an application?
• An application is a physical interface (group of
screens) and database tables that provide a
coherent set of transactions to support a particular
business or administrative objective.
• An application may take the form of a single
Delphi Project or a number of linked Projects.
• In MS Access an application may take the form of
one or more .mdb files.
• In e-commerce, an application is a set of HTML
pages, server programs, and databases.
April 2002
2/CS/3X
APP 3
An e-commerce application
Tier 1
Browser
April 2002
Tier 2
Web server
2/CS/3X
Tier 3
Database
APP 4
What is a transaction
• A single identifiable task with a definite
objective, for which the user employs a
software application
• A transaction may change the database in
some way.
• A transaction may produce some (printed or
displayed) output from the database.
April 2002
2/CS/3X
APP 5
Examples of transactions
• Student registration
– Register a new student on a degree course
– Register an existing student for one or more units
– Print a list of students registered for a unit
• Bank account
–
–
–
–
Open an account
Enter a deposit transaction
Enter a direct debit mandate
Print a statement
April 2002
2/CS/3X
APP 6
Analysis of transactions
What inputs are required?
What outputs are expected?
What changes to the relations in the database are
expected?
What errors should we guard against?
What rate of usage should we expect?
How important is this transaction to the users?
April 2002
2/CS/3X
APP 7
User interface design guidelines
Use meaningful titles for screens and reports.
Use familiar terminology in instructions.
Keep related fields together – be consistent.
Make the screen or report look attractive.
Be consistent about the use of colours, terminology, abbreviations, and so
on.
Make the data entry areas clearly defined and of the right size, and show
which fields are optional and which are required.
Allow correction of errors for characters and entire fields.
Produce sensible and informative error messages, free of value judgements.
Provide help information for each field.
Let the user know when the input is complete, and give an opportunity for
review.
April 2002
2/CS/3X
APP 8
Permanent database files
• Hold the “strong entity types” plus the
“weak entity types” created during logical
database design
• Though records may be added and deleted,
these files are not usually empty
April 2002
2/CS/3X
APP 9
Queries
• A group of operations (usually written in SQL)
that perform routine transformations on tables
• In Access the term “query” includes select, update,
delete, maketable, crosstab, etc.
• In Delphi these are handled by separate
components (i.e. not grouped together under the
general heading “queries”)
April 2002
2/CS/3X
APP 10
Reports
• Summarise information in the database
• Produce printed documents from database
– invoices, catalogues, price-lists, monthly banking
reports
• Facilities for subtotalling and grouping, headers
and footers
• May be printed or displayed
• In Delphi see ReportSmith
April 2002
2/CS/3X
APP 11
Key points
• An application serves a group of users, and
gives them an interface to transactions that
access a database.
• Electronic commerce is a prominent source
of database applications.
• User interface design needs care if the users
are to be well-served.
April 2002
2/CS/3X
APP 12