The fact that only three of the five clubs use modern computer databases for handling their member’s data prevents information from being properly, efficiently and conveniently synchronized, updated, edited and stored. In the last year over two thousand members have complained about the bad management, and found that although they may be a member at one club, if they go to another club they are not recognized as a registered member and must reregister, and over 1,500 have recently left for similar reasons. This causes big problems for Squaresoft© to overcome. So I have been asked to help.
Analysis
The following five clubs use old-fashioned ledger driven management.
- Final Fantasy Project (Maidenhead)
- Old fashioned ledger driven management, 2529 members
- Final Fantasy Extreme (Slough)
- Old fashioned ledger driven management, 1038 members
- Ultimate Final Fantasy (Burnham)
- Old fashioned ledger driven management, 543 members
- Final Fantastic (Beaconsfield)
- Old fashioned ledger driven management, 275 members
- Final Fantasy City (London)
- Head club, old fashioned ledger driven management, 4593 members
Input from the members is gathered in the following stages:
Members are encouraged to play the demo games located around the area, and are visited at regular intervals by workers who give them a survey, which is written down into a handwritten file and stored. Later the file is sent to Final Fantasy City in London, and eventually sent to Squaresoft were the ideas are used in the latest games.
Another inefficiency is the users. The users names and information are stored in a ledger, and users who visit different clubs aren’t recognised as a registered member and they have to sign up again. This is a frustration and will need to be updated.
Specification
Members will be encouraged to play the demo games located around the area and enter their user name and password to access them. At regular intervals, the game pauses and a survey comes up, when it is fully completed it is sent off and stored into a relational database, and they can continue playing. Since the server knows who is signed in, they never get the same survey twice. The relational database is set so that once ten survey entries have been stored, they are sent off to Squaresoft and stored in hard copy, and the relational database is reset.
When the server is set up, the users’ usernames, passwords and information will be stored in a relational database and easily accessed from all clubs, so the users are registered to any club and can freely access all of them.
Tables
Clubs:
Datasheet View:
This is the datasheet view of my Clubs table. In this table, I listed my five clubs, along with their addresses and post codes.
Design View:
This is the design view of my Clubs table. This example shows how I set the ID to automatically increment for every row of information.
Customer:
Datasheet View:
This is the datasheet view of my Members table. This table lists all of my members and lists their addresses and phone numbers.
Design View:
This is the design view of my Members table. I wrote a description for each one.
Queries
Clubs Members Query:
Datasheet View:
Design View:
Clubs Members Query 2:
Datasheet View:
Design View:
Design View:
Customer Query:
Datasheet View:
Design View:
Forms:
Clubs:
Datasheet View:
Design View:
Christian Augustine Page of
