GENERAL REQUIREMENTS
You are required to design and implement using Access, a business-related database application based on a scenario of your choice. For resit purposes it is suggested you use a bookshop as the basis of your project.
This assignment counts for 40% of your total mark of the BIT module and therefore must be a significant piece of work in terms of both time and quality. While the application must be usable, it need not necessarily be a finished product.
Your assessment is comprise of 3 element
1) A report on database design
2) A user guide
3) Your database
1. DESIGN SPECIFICATION
This should include the following:
• An indication of the intended user of the application and how you think that the business operation can be improved by using your application.
• Some terminology in your additional features (field names, reports, etc) might be unfamiliar to your tutor. If so, you should include sufficient documentation to enable her to fully understand your database design.
• Either an E(A)R diagram or a printout of the ACCESS relationships window. The latter may be obtained via the FILE menu.
• A completed Table Layout Sheet for each table (see pg. 9 of assignment brief).
• A brief list of the most important components together with an indication of their purposes, functionality and underlying table(s)/query(ies). In most cases, the list will probably consist of a small number of forms and at least one report.
• Any additional relevant information.
2. YOUR DATABASE FILE(S).
Your file(s) may be submitted as follows:
• A printed copy of your report
• A copy of your database on CD-ROM or DVD.
You must make sure that you keep an identical copy of the file(s) for backup.
3. FULL DOCUMENTATION
A full report documenting the development and function of your database, along with a guide that is targeted to a typical user (that you have identified). You can include screen-shots – which can be very useful and give a more professional look.
You should include:
• Front page (including your name, ID and tutor name)
• Contents page
• Your design specification report must include the following – see section 1, above
o Details and justification of any assumptions and decisions made which reflect your understanding of user requirements and potential issues with users’ interaction with the system (e.g. level of users experience in using databases). Identify any features you have included/not included to better suit users’ needs and any assumptions you have made regarding your users in order to make these design decisions
o A list and brief description of any components not included in the user guide, that you would wish to be assessed. You may also wish to make reference to parts of the user-guide. Emphasise any particular features that you think could be overlooked.
o An indication of any unusual features (such as use of additional software).
o An indication of any limitations of the system.
o An indication of additional features that you would like to include, given further time and/or expertise – in particular, an indication of how you would attempt to rectify any bugs or faults, given sufficient time.
o A list, if relevant, of any parts of the database which are not your own work – e.g. any components of the Northwind database, which you have utilised. Failure to provide such information could be classed as plagiarism.
o Any other documentation which you deem to be relevant.
This documentation is to be word-processed but must be submitted in hard-copy form.
• A user guide, including:
o User instructions at a level appropriate for ‘the typical user’. Generally speaking, the more user-friendly the database, the less user instructions should be necessary.
o A list and brief description of all those components of the application that the user might need to know about. This is likely to include all forms and reports. You should be particularly careful to explain the purpose in cases where it is not obvious. A generalised description of the purpose or nature of a table, form, report, query etc. is not expected.
o A description of any bugs or faults
4. FRONTSHEET
This should include the following information:
• Student Name
• Access Version
• Name of file(s) (and path, where appropriate) and Database Password (if used).
IMPORTANT NOTES
Please refer to Access booklets 1-4 used in tutorials for guidance
Validation
Validation of data input is an important feature of any application. While you may well input some data early on, for development purposes, it is essential that you fully test your data input forms AFTER all your validation is in place.
Wizards
You are expected to make use of the Access Wizards, which have been introduced in the booklets. However, a student who limits his/her database design work to the execution of wizards is unlikely to obtain a high mark for the assignment.
Switchboards
It is expected that your system will be driven by a switchboard (Access book 4). When assessing your submission, forms and reports which are accessible from the switchboard will normally be the only ones assessed – unless the documentation (examiner’s guide) draws attention to others and explains why they are not on the switchboard system.
Queries
Students may wish to include queries which are unlikely to be particularly relevant to users of the database in order to demonstrate their ability to handle additional features. Such queries need not be accessible from the switchboard but should be noted in the Examiner’s Guide.
Access Versions
During tutorials you have been using Access 2007. Please gain permission from your tutor if you wish to submit your database using other versions of Access or other software.
PLAGIARISM
Plagiarism, whether of other students’ work or from published works, is totally unacceptable. Evidence of plagiarism will be reported to the University Discipline Committee. This will probably mean that the results of the student(s) involved will be withheld and, if found guilty, the minimum penalty is a mark of zero for the complete module.
Database Size
Access files can often get unexpectedly large (particularly if you include lots of graphics). This is usually not too much of an issue given the huge amounts of storage now available fairly cheaply. However, if you should find you have a storage problem, database files can often be reduced in size without loss of content. You should first try doing this within Access, proceeding as follows:
• Tools
• Database Utilities
• Compress and Repair Database….
If, after trying this, you still need to compress your file further, you should use WinZip.
Use of New or Advanced Technology
Students are certainly encouraged to look into more advanced features of Access that have not been covered in the guides. However, you should bear in mind that use of ‘high technology’ can result in problems of access for internal or external examiners, who don’t necessarily have the required hardware or software. Please bear this point in mind and consult your tutor if in any doubt.
SUBMISSION DATE
The assignment should be submitted on or before Friday 29th August 2014
STAGES IN THE DEVELOPMENT OF YOUR ACCESS ASSIGNMENT (AND OTHER USEFUL NOTES)
1. DETERMINE APPLICATION
First, a general point – don’t try to be over-ambitious. Better to start with limited aims and then add further functionality as time allows. If you spend too long developing a complicated structure, you may find you’ve no time to show off the variety of techniques that you’ve learned.
2. INITIAL DESIGN
Make sure that you produce an appropriate design before you actually sit down at the computer. Failure to do this properly can lead to problems at a later stage and a possible need for re-construction of much of your database. Clearly, the more complicated your application, the more important is this stage. You are strongly advised to seek feedback on your design before progressing with detailed implementation.
2.1 The EAR Model
Carefully think about and research into the entity sets that are required. (If you are producing a database for a real organisation, you should consult the appropriate personnel). It is difficult to suggest a minimum or maximum number of entity sets as this will tend to depend on the type of application.
List the attributes of each entity set and indicate primary keys. Perhaps most importantly, think carefully about the cardinality (1-1, 1-n or n-m) of each relationship and deal appropriately with those that are many-many.
Carefully construct your E-R diagram. However, don’t worry too much about presentation, as you will probably prefer to submit a print-out of the Relationships Window. Just make sure that you can refer to the E-R diagram as you construct your database structure.
STAGES 3 ONWARDS INVOLVE THE USE OF ACCESS
3. CREATE THE DATABASE FILE
All the components of your database will normally be contained in a single Access database file. The creation of this is very simple – as you will have seen in Access book 1.
4. CREATE THE VARIOUS TABLES IN YOUR DATABASE
By now, you should have a clear structure for each table on paper. This stage then involves the construction of each one in your database file. (Worked examples of how this is done can be found in Access book 1).
4.1 The LOOKUP WIZARD
The Lookup Wizard should normally be utilised for each foreign key field. It has the following significance:
• The actual link between two tables (primary key to foreign key) is created automatically by Access as part of the Lookup Wizard process
• The relationship thus established is included in the Relationship Window
• It provides a look-up facility for the user
4.2 VALIDATION
At this stage, simple validation rules should be established.
If necessary, additional validation procedures (including those which require more advanced techniques, such as macros) can be added later.
Once you have created all your tables (and the corresponding relationships), don’t forget to ensure that all tables and links are represented in the Access Relationship window.
If you haven’t done so after stage 2, you might, at this point, want to get feedback on your database structure.
5. IMPROVING YOUR DATABASE
ONCE YOU HAVE SUCCESSFULLY COMPLETED STAGES 1 – 4 YOU CAN THEN THINK ABOUT DEVELOPING THE SOPHISTICATION OF YOUR DATABASE IN THE FOLLOWING AREAS:
Input Forms
Various types of Queries and Reports
A Switchboard System
Further validation (possibly including use of simple macros)
Graphics/Charts
Addition of further functionality to your forms, by means of command buttons
Security Measures
6. ENTERING DATA
NOTE: YOU SHOULD NOT ENTER LARGE AMOUNTS OF DATA UNTIL YOU ARE FULLY SATISFIED WITH YOUR STRUCTURE AND YOUR VALIDATION.
Remember that data is normally input via a suitable form. You should therefore create a form to facilitate data entry to each of your database tables (sometimes, one form will be used to update more than one table. Whilst entering data, the various validation and LookUp procedures should of course be effective.
FURTHER USEFUL POINTS
7. USER-FRIENDLINESS
User-friendliness and validation are important (perhaps the most important) aspects of any application.
a) It’s a good idea to get friend(s) to test-run your application
i) See if they can navigate the application with little guidance;
ii) Get them to attempt to break through the validation.
b) Make sure that lookup facilities, which you’ve attached to your tables, carry through to the appropriate input forms. There should be no problem with a lookup table or lookup list that is associated with a table before the corresponding form is created. However, lookups attached to a table after the form is created do not seem to be accessible from the form. The Lookup Wizard is not available from form design but the Combo Box Wizard does the trick.
c) Validation rules attached to a table will be operative at the form level, even if created after the form. However, you may prefer to attach them to the form itself rather than the table (Open Properties for the appropriate field and Default Value, Validation Rule and Validation Text will be found under the Data tab).
d) Ensure that you have not made things unnecessarily difficult for the user. For instance:
• Are you requiring data to be input twice (suggests that you need to amend your design. Except in the case of a primary key and the corresponding foreign key(s), a particular field should never appear in more than one table – though it may appear in several different forms)
• Are you expecting data to be input in an unnecessarily lengthy way (use a LookUp?)
• Are you expecting the user to know information such as customer IDs (use a LookUp)
• Bear in mind when creating parameter queries (or any other modes of input), that it must be made clear to the user exactly what type of input is required.
Example Table Layout
Table: PRODUCTS
Field Name Primary Key Foreign Keys Table containing Corr. Primary Key Type Validation / Comments
Product ID (Auto) Number –
Product Name Text (30) Letters, digits, spaces?
Supplier ID Suppliers Table Number (Integer) Lookup Wizard (Ref Integrity)
Category ID Categories Table Number (Integer) Lookup Wizard (Ref Integrity)
Quantity Per Unit Text (20) Probably not easy to validate
Unit Price Currency >0
Units In Stock Number (Integer) >0
Units On Order Number (Integer) >0
Reorder Level Number (Integer) >0
Discontinued Yes/No Default: No
TABLE LAYOUT SHEET
Table:
Field Name Primary Key Foreign Keys Table containing Corr. Primary Key Type Validation / Comments
Use the order calculator below and get started! Contact our live support team for any assistance or inquiry.
[order_calculator]
