Microsoft Access '97 – 2003 | Page Two | The Design Process
Wanting to learn about Microsoft Access? These pages include an introduction for beginners, design process, questions and answers, a glossary.
Page: 1 of 4 | 2 of 4 | 3 of 4 | 4 of 4
Before you begin
Before creating a database, it is perhaps appropriate to plan – this would likely begin with an analysis of the tasks required of the proposed database.
Perhaps consider or establish exactly why you or prospective users require a database – what will be its function? Where applicable, discuss with users to get a thorough description of expectations. Keep in mind that the design process is an iterative one (Going back over, repeatedly starting from the beginning to ensure added features work). Familiarise yourself or the proposed user with form and report capability by demonstrating some data entry forms showing examples of printed reports.
Database design can perhaps be broken down as follows:
Assess what the users want from the database and what data is needed for output.
What do the users want to get from it?
What kind of reports?
How do they want the information arranged?
Consider existing formats for data collection.
Look at other 'similar' database designs.
Plan the data distribution.
Identify the fields for each table.
Assign a unique field for each table that will ensure that no two records are the same.
Determine how the tables are related to one another.
Review design and step through procedures with users.
Create tables and enter data.
Analyse and optimise database performance.
For the more advanced
The objective
What precisely is the new database system needed for?
Problem definition
Is the current system suitable?
Do records move around?
Are they liable to be lost or misplaced?
Is current practice repetitive?
Are there confidentiality and/or backup concerns?
Feasibility study
Are current computers suitable?
Has an interim report been made?
What has been established?
What is required to meet needs?
Proposed system
Consider if clients need to complete paper forms for batch processing by staff.
Consider if any data is required to be entered in real time.
How many records is the database likely to house.
Do all users need to have access to confidential tables?
Perhaps also consider both hardware and hardware security.
Maybe include an option to facilitate backup and safeguard data.
Are there any preferences?
What software, software security might be needed?
Is the budget adequate?
Analysis
Perhaps further take into account all sub-sections, security confidentiality issues, and any related information.
Design
A proposed structure would perhaps be included along with suggested data for testing and debugging.
Implementation and evaluation
When is the system to be installed and tested?
Will staff training take place during this phase?
Maintenance
What measures are needed to ensure the system continues to function properly?
Consider field testing.
Perhaps write and implement escalation and fault reporting procedures.
Is assistance with policy and procedure needed?
Maintaining data, and issues relating to the Data Protection Act, as with Health and Safety, will perhaps be managed in-house.
