Creating a computer system Essay

1. 1 Introduction Wooten Basset Rugby Club, are a rugger club in the Swindon area, whom play 15 a side rugby union. They put out a numbers of police squads each(prenominal) week ranging from junior levels, senior teams and womens rugby. Of my concern is the U-16s, whom would like to computerise a number of tasks and meet a reference for relevant in spend a pennyation including musician and parent information. In any particular season there lead be among 20 and 30 players at the club. These players are trained by the in tellect 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 interpreter 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 jade and tedious work. info is currently stockd in f iles kept at the head coachs house. This system of holding information has become unreliable as over the history of the team players get down moved on or changed their details.When this occurs due to time constraints, managees for example are often added to rather than modified creating both distinct addresses complicating matters when important letters need to be sent. In the past when players have left their file has non been removed leaving large amounts of nugatory 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 implore 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 holding which is difficult due to the above reasons. The current system has no scope for evaluating players from teams t he club faces. No data is kept on players from other teams like their marker or disciplinal constitutions. They can therefore not assess before a fixity 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 pr integrity to being lost making analysing a players progress somewhere between difficult and impossible. besides they are unable to shoot the breeze which players are the top scorers or most ill disciplined. bullion 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 break loose this payment and the referees payment is short. Yet with at least 15 players playing in every match temperaments of owes m geniusy 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 drug users for the system. This will give a good insinuate 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 more or less a match its date, venue and other relevant information. Invitation letter to other clubs inviting them to a match. Player and parent data. Store get to details well-nigh 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 clubs leading scorers and those with the polish off 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 i2. Other important points taken from the interview System must be as gondolamated as possible as user wants system to save him time. Simple user interface. some(prenominal) of the coaches whom will use the system have very little knowledge of computers and will struggle with a complicated system. System will be perish from head coachs 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 rate of flow data will be deleted and new record wil l be kept. Hold data relating to tournament and determine the clubs 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 split up 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 bring out 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 order 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 nominate Christian and Surname only Parent Store parents name for contact details. Address1 Store first line of a players address. Address2 Store second line of a players addres s 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 flake Membership Paid Whether a player has paid membership fees for current year or not. FIXTURES handles data revolving each fixture vie 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 remote key which identifies which tournament a fixture belongs to. Friendly fixtures will be determined by a specific code. Date Venue Select from every 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 tw o teams having the same name. Team Name Name of each rival team. Telephone Address1 First line of each teams address. Address2 Second line of each teams 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 place by using a players membership code and the corresponding fixture code, these two international keys will create a manifold key. Each player may have played in many fixtures and therefore have many records in Players-Fixtures. This creates a one to many alliance between, Players and Players-Fixtures.Similarly many records in Players-Fixtures may relate to one fixture and so a one to many relationship outlives 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 set using the foreign keys of rival player code to determine which player, and fixture code to determine t he 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 fro m 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 pass judgment Design Following are description of all the places to be stored in the system 2. 3 Form Design In order for the user to act 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 good 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 change the users 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 na vigate through the system. For validation the training attribute uses a combo box to ensure the user enters the objurgate 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 fixtu re is selected it will open air 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.