Creating a computer system Essay Example for Free

Creating a computer system try1. 1 Introduction Wooten Basset Rugby Club, are a rugby club in the Swindon area, whom vivify 15 a side rugby union. They put out a subdues of teams severally workweek 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 construct a indication for relevant selective information including sham and parent info. In some(prenominal) ill-tempered season there leave be between 20 and 30 players at the club. These players are trained by the wellspring tutor and around ternary new(prenominal) coaches all of whom are made up of parents of the players. The head coach is obligated 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 once against a rival team a letter is written specifically for to each one player. With as many an(prenominal) as 3 0 players at the club, this is tiring and tedious work. data is currently stored in files kept at the head coachs house. This system of holding information has give-up the ghost treacherous as over the history of the team players nurse moved on or changed their details.When this occurs due to clock time constraints, addresses for example are often added to rather than modified creating two distinct addresses complicating matters when important letters necessitate to be sent. In the past when players have left their file has non been removed leaving bounteous 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 set up by dint of memory wh ich 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 disciplinal records. They fuel consequently not assess before a unalterability which players are a danger and tactics suffer. gain ground and disciplinary data is stored on paper kept in files. This data is again not puff up managed and prone to being lost making analysing a players progress somewhatwhere between difficult and impossible. in like manner they are unable to see which players are the top scorers or most ill discip contestationd. Money watchfulness 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 referees payment is short. Yet with at least 15 players playing in every match records of owes money are not kept and this information is scarcely forgott en. 1. 3 Interview Summary In place to create this system it was important that I shoot an interview with one of the end exploiters for the system. This result give a good outline of the requirements for the system.The interview was with the head coach whom lead be the predominant exploiter of the system. From the interview this is an outline of what the new system get out have to achieve Produce template letters for a number of issues. These letters include see to it details, which ordain 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. police squad 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 clu b. 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 worst disciplinary records. Store data about what character of training each player is on. For example some players whitethorn 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 automated as possible as user wants system to save him time. Simple user interface. several(prenominal) of the coaches whom pass on use the system have very little knowledge of computers and will struggle with a complicated system. System will be run from head coachs lap top computer and thusly not need any network capabilities. Head coach has copies of Microsoft Access already stored on his computer. IT birth consists exactly 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 fall 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 divided this data into the following throngs Players, Fixtures, rivalrys, Rival Players, Players-Fixtures and Rival Players-Fixtures. A primary key will be used in every case to grotesquely identify each record, these are marked by these symbols, and . PLAYERS deals with data relating to players such as membership and contact detailsMembership Number 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 find Christian and Surname only upgra de Store parents name for contact details. conduceress1 Store first line of a players address. Address2 Store second line of a players 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 compete or to be played Fixture Code 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, aught 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 star sign or away.Round Determines which round of the competition, f or example first round or semi final. RIVALS holds data on teams played by the rugby club, this includes contact details Team Code 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 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 informationMembership Number Used to identify player for which record is stored. Fixture Code Identifies which fixture record relates to. Tries Number of tries scored by a particular player in each fixture. Penalties All penalization 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 -T he amount paid will be displayed from. TOURNAMENT holds data relating to tournaments the clubs plays in Tournament Code Unique code which identifies each tournament.Winner eventual(prenominal) 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 victimization a players 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 alliance between, Players and Players-Fixtures.Similarly many records in Players-Fixtures may relate to one fixture and so a one to many relationship inhabits between Fixtures and Players-Fixtures. The Rival Players-Fixtures data store is similar to Pla yers-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. iodin 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 repor ts, 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 jazz band 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 users navigation of the system a jazz gr oup 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 precept to the Fixtures form. There are button to add and delete Player records and there is also a jazz band 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 cover 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 preceding(prenominal) 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 examination Design For the system to perform the function required of it queries are used to extract the precise data from the database.