Creating a computer system Essay

1. 1 Introduction Wooten Basset Rugby Club, are a rugby club in the Swindon area, whom play 15 a side rugby union. They put out a numbers of teams each week ranging from junior levels, senior teams and women’s rugby. Of my concern is the U-16s, whom would like to computerise a number of tasks and have a reference for relevant data including player and parent information. In any particular season there will be between 20 and 30 players at the club. These players are trained by the head coach and around three other coaches all of whom are made up of parents of the players. The head coach is responsible for much of the current administrative work. 1. 2 Current System Currently all tasks for the club are carried out manually. For example when organising a match against a rival team a letter is written specifically for each player. With as many as 30 players at the club, this is tiring and tedious work. Data is currently stored in files kept at the head coach’s house. This system of holding information has become unreliable as over the history of the team players have moved on or changed their details. When this occurs due to time constraints, addresses for example are often added to rather than modified creating two distinct addresses complicating matters when important letters need to be sent. In the past when players have left their file has not been removed leaving large amounts of useless information. All of this complicates matters when searching for data making the process longer and increasingly unreliable. Among the squad of players, each player has his own specific needs. For example different players require different training methods such as fitness or tactics. With many players and few coaching staff it becomes difficult to organise. Currently this is organised through memory which is difficult due to the above reasons. The current system has no scope for evaluating players from teams the club faces. No data is kept on players from other teams like their scoring or disciplinary records. They can therefore not assess before a fixture which players are a danger and tactics suffer. Scoring and disciplinary data is stored on paper kept in files. This data is again not well managed and prone to being lost making analysing a player’s progress somewhere between difficult and impossible. Also they are unable to see which players are the top scorers or most ill disciplined. Money management is also a problem. Fees used to pay math officials are deducted form the fees paid by players. This is organised by the coaches, however often players miss this payment and the referee’s payment is short. Yet with at least 15 players playing in every match records of owes money are not kept and this information is simply forgotten. 1. 3 Interview Summary In order to create this system it was important that I conduct an interview with one of the end users for the system. This will give a good outline of the requirements for the system. The interview was with the head coach whom will be the predominant user of the system. From the interview this is an outline of what the new system will have to achieve: Â  Produce template letters for a number of issues. These letters include Match details, which will tell players about a match its date, venue and other relevant information. Invitation letter to other clubs inviting them to a match. Player and parent data. Store contact details about players and parents. Â  Statistics. Store statistics on players including points scored, tries and appearances. Â  Team information. Store details on rival teams such as contact details. Fixtures. Store fixture information including scores, dates and venues. Â  Ability to see reports on players from the club. Â  An ability to track membership payments. The system must indicate whether a players has paid his membership for that season. Â  Create leagues of the club’s leading scorers and those with the worst disciplinary records. Â  Store data about what type of training each player is on. For example some players may have fitness training or others forwards training. Monitor finances for each fixture. For each fixture a player has to pay a fee of i 2. Other important points taken from the interview: Â  System must be as automated as possible as user wants system to save him time. Simple user interface. Several of the coaches whom will use the system have very little knowledge of computers and will struggle with a complicated system. Â  System will be run from head coach’s lap top computer and therefore not need any network capabilities. Head coach has copies of Microsoft Access already stored on his computer. IT experience consists only of use of Microsoft applications. Â  Data on fixtures and statistics only to be kept for one season at a time. After this period data will be deleted and new record will be kept. Â  Hold data relating to tournament and determine the club’s progress in these tournaments. 1. 4 Data Requirements From the interview it has become apparent that I will need to store a considerable amount of data. I have divided this data into the following groups: Players, Fixtures, Rivals, Rival Players, Players-Fixtures and Rival Players-Fixtures. A primary key will be used in every case to uniquely identify each record, these are marked by these symbols, < and >. PLAYERS deals with data relating to players such as membership and contact details: – A unique code used to identify each player. Each Membership code is made up of three numbers and a letter. The letter represents the age group, as this letter only deals with one age group each membership code will have the letter, E. For example, 001E Name – Christian and Surname only Parent – Store parent’s name for contact details. Address1 – Store first line of a player’s address. Address2 – Store second line of a player’s address where applicable. Postcode Training-What type of training the player is on. User will only be able to select from these values: Fitness, Backs, Forwards or General. Telephone Number Membership Paid – Whether a player has paid membership fees for current year or not. FIXTURES handles data revolving each fixture played or to be played: – Identifies each fixture uniquely as some fixture may be against the same team. Team Code – Determines which team is to be played or has been played Team Score – Score for Wooten Bassett, null if not played. Rival Score – Score for rival, null if not played. Tournament Code – Foreign key which identifies which tournament a fixture belongs to. Friendly fixtures will be determined by a specific code. Date Venue – Select from either home or away. Round – Determines which round of the competition, for example first round or semi final. RIVALS holds data on teams played by the rugby club, this includes contact details: – Each team will be assigned a unique in case of two teams having the same name. Team Name – Name of each rival team. Telephone Address1 – First line of each team’s address. Address2 – Second line of each team’s address if applicable. City Postcode Directions – Description of how to reach rival club. PLAYERS-FIXTURES relates to the actions of players in each fixture, this includes scores and disciplinary information: – Used to identify player for which record is stored. – Identifies which fixture record relates to. Tries – Number of tries scored by a particular player in each fixture. Penalties – All penalty kicks converted by a player in a fixture. Drop Kicks – All drop kicks scored by a player in a fixture. Disciplinary – Whether a player was disciplined in a fixture and what level of action, a yellow card for example. Fee Owed -The amount paid will be displayed from. TOURNAMENT holds data relating to tournaments the clubs plays in: – Unique code which identifies each tournament. Winner – Eventual winner of tournament. 1. 5 Entity Relationship Diagram This diagram of how data will be kept in the new system. The Players-Fixtures data store will link Players and Fixtures together. It will store data relating to what a particular player does in each game. Each record will be identified by using a player’s membership code and the corresponding fixture code, these two foreign keys will create a composite key. Each player may have played in many fixtures and therefore have many records in Players-Fixtures. This creates a one to many relationship between, Players and Players-Fixtures. Similarly many records in Players-Fixtures may relate to one fixture and so a one to many relationship exists between Fixtures and Players-Fixtures. The Rival Players-Fixtures data store is similar to Players-Fixtures, however it stores data about rival players as opposed to players for Wooten Bassett rugby club. Each record will be uniquely identified using the foreign keys of rival player code to determine which player, and fixture code to determine the fixture. Again a one to many relationship exists between Fixtures and Rival Players-Fixtures as one fixture may have many related records in Rival Players-Fixtures. Each Rival Player may have many records in Rival Players-Fixtures as they have played in many fixtures, a one to many relationship will exist here. Wooten Bassett will face many different rival clubs with many different Rival Players. Therefore Rivals will store data about all rival clubs and each record will be uniquely identified by team code. Rival Players will store data will store data about all the players who play for these clubs will be identified by the rival player code. To determine which player plays for which club Rival Players will have the foreign key Team code. This means many Rival Players can play for one club, again a one to many relationship will exist here. Each fixture will be against one of the teams detailed in Rivals. In order to identify which team is being played the foreign key, team code from Rivals will be used. One Rival may play in many fixtures creating a one to many relationship from Rivals to Fixtures. Tournament holds data relating to competitive fixtures. Therefore one tournament will have many records in fixtures, and again a one to many relationship is present. 1. 6 Data Flow Diagrams 2 Design 2. 1 System Design. The system will be divided into five entities described in Analysis. These are Players, Rivals, Fixtures, Players-Fixtures and Tournament. 2. 2 Attribute Design Following are description of all the attributes to be stored in the system: 2. 3 Form Design In order for the user to interact with the system, it must be presented in a user friendly interface. Within Access this is done using forms and reports, each form should allow the user to easily understand the information and be able to perform sufficient actions such as adding or deleting data. Following are the forms required by the system: 1. frmFixtures. This form will deal with all the actions relating the handling of data with fixtures. Here the user will be able to add, alter or delete any records from the Fixtures table. For example if a new fixture has been organised then the user can use the Add Fixture button to add a fixture to the schedule. Also changes to the date for example can be made. In order to maintain the consistency of data validation is being used. The FixtureCode attribute is updated automatically as an auto number preventing the user from making mistakes. Also a TeamCode will be selected from a combo box so a user cannot enter a team that does not exist. Also only two values will be able to be entered into the Home/Away attribute, home or away. To simplify the user’s navigation of the system a combo box at the top of the form allows the user to select any existing record quickly. 2. frmPlayers The Players form works on a similar principle to the Fixtures form. There are button to add and delete Player records and there is also a combo box to allow the user to navigate through the system. For validation the training attribute uses a combo box to ensure the user enters the correct value and an input mask controls the MembershipNumber, so that data is entered in the appropriate format. 3. frmRivals Again the Rivals form works in a similar fashion to Players and Fixtures. Buttons on the right control adding and deleting functions and a combo box is used for navigation. Validation is ensured by using an auto number data type to automatically update the TeamCode attribute. 4. frmTournament The tournament form works exactly the same as the previous forms, with add and delete buttons clearly labelled and a combo box for navigation. The TournamentCode attribute does not require input as it is an auto number ensuring validation. 5. frmFixture Statistics This form is directly different form the previous forms. In this form a user can manipulate data in the Players-Fixtures entity. The user can view specific fixtures through a combo box, when a fixture is selected it will open a sub form containing all the data about the players whom played in that match. Here new data can be added about a fixture or incorrect data can be corrected. The FixtureCode and MembershipNumber attributes will be controlled by a combo box, eliminating user error and the consistency of the data. 2. 4 Query Design For the system to perform the function required of it queries are used to extract the precise data from the database. Â