Table of Contents Executive Summary 2
Download 471.88 Kb.
|
- Navigate this page:
- 2.2 Figure 1: Database Access Pathing
- 2.2 Figure 2: Basic Database Structure
- 2.2 Figure 3: Database Access Privileges
- 2.2 Figure 4: Database Cloud Computing
2.2 Database DevelopmentTo facilitate data storage, both during games and after games, a database structure must be implemented in order to sort, organize, and access data in a timely manner for use of analysis and feedback. The data must be accessible on the fly, with the ability to read data to both the spectator clients, as well as the coach and umpire clients. The database will be consistently accessible for reading and writing, using special access privileges to control the data flow. As the backbone of the entire data system for scoring and analysis, the database structure will store and organize player and game data, both during and after games, to allow the players, coaches, and umpire to have immediate access to specific and detailed data.Key data which must be actively accessed during a game include runs, outs, batting counts, fouls, balls, and innings. Additionally there will be data that is not used directly with the game being played, but rather for grading and scoring the players and teams individually; data such as batting averages, pitching averages, and player efficiency. Some of the data being stored while the game is in session is essential for monitoring the game itself. Outs, fouls, and balls will be used to determine when teams rotate positions, and the actual score. Pitchers in minor league games are limited to how many times they can pitch per game. This count is essential, as the coaches are currently managing these numbers manually. The database can easily store, track, increment, and be used to trigger alerts to the coaches and umpire as to when a pitch limit has been reached. The database itself is sorted by team name and individual players. Each data set, depending on the roles each player can fill, can store such things as average scoring, runs per game (sorted by individual games), batting averages, and other data the coaches deem important. Additionally, since all of the data is readily available and organized on a per-game or per-team basis, the data can be easily accessed and analyzed for output, for the coaches to analyze their team performance and decide where to make improvements. Since data is constantly flowing during games, this means that each individual client will need to have custom read/write privileges depending on their role, and the data must be retrieved and organized in such a manner to fit that role. This means the coaches and umpires will have write capabilities, and the umpire will have final confirmation privileges on all data, and is responsible for solving disputes (data inconsistencies). Any scoring discrepancies will be solved through the umpire, and the final data solution will be written to the database, and only this data will be accessible. Spectator clients will have immediate access to all data, including individual scoring, and play calls, as they occur. Spectator clients, coaches, and the umpire have different access privileges to the database. This means each client will require unique rights to access the database itself, and the data must be returned in a manner that is most beneficial to the requesting client. For example, coaches will require more detailed information for players, than a spectator client would. Since all clients are accessing the network from the same source material, clients who require special privileges (the coaches and the umpire) will be required to authenticate themselves, via login or unique identifier, in order for the database to serve and verify their requests. Other clients, the spectators, only have read privileges, and should only access data available to them. Given the properties of database structures, this means the coaches and the umpire can choose to hide or protect pieces of data from the spectators, with their given rights. 2.2 Figure 1 displays the two types of data accesses that can occur from the clients. Dependant on the source, the database must respond to each query accordingly. 
2.2 Figure 1: Database Access Pathing For data implementation, the server will organize each player and team into their own database tables. The team itself is the source of each database structure, with all player data, specific to each game, sorted within the database tables. This data is simply stored as values, which can be read or wrote at any time. More data columns per player can be easily added on the fly, and accessed at any point thereafter. By organizing the data storage templates into player-based categories, the entirety of each player’s data can be immediately accessed at any time. Additionally, since these values are dynamically updating, they can be used within the scope of the current game being played. A team’s current standing (score, outs, etc) can be instantly calculated by using each individual value. Depending on server strain due to excess data access, from the clients or from the data processing, this data can be accumulated into its own table, so scores and other game-dependant values can be accessed individually. The purpose of this extra database table would be dependent on the situation in which the data is being accessed; if the game is currently active, or if no game is currently being played. 2.2 Figure 2 displays a basic structural outline of a database under this type of design. 
2.2 Figure 2: Basic Database Structure For I/O accesses to the database, the operation will depend on the privileges given to the requestor. By default there are no restrictions on reading capabilities; that is, any of the clients trying to access existing data in the database, which is controlled by the application itself. The actual privileges each client receives depends on the role being fulfilled. Thus, some clients will have database write capabilities to certain areas, while other clients do not. Since there are three different client types, and multiple users per type, the database must now decide how to prioritize data operations. If a spectator requests a player summary, or a score summary, while a higher priority client (Coach or Umpire) is attempting to write to the database, a data conflict occurs. To solve this issue, the software needs to control data accesses in such a way that allows the database to finish modifying values before the client request is allowed. Long-term data storage is an issue as well, since player data will accumulate over time. This means each baseball field utilizing the program will require some form of consistent data storage to maintain the database. Fortunately, MySQL and other database maintenance utilities make back-ups and restoring files automatic, and simplistic. Even if the database needs to be transferred or altered within the system, it can be easily completed. However, if no long-term data storage is necessary, that is, if the data is no longer needed after a game is completed, the databases themselves can be erased, and the data storage issue is no longer a concern. When specifically implementing the database server, there are a few methods of design. The database can be run by a physical server, a computer located within wireless range of the baseball field. Another option is using a cloud service, such as Amazon, for remote database access via the Internet. This provides some convenience bonuses, since the computer itself is no longer required, but places more strain on the local network, as the devices must make constant Internet accesses to retrieve database information. This generally would be slower than a locally stored, directly accessible computer system. To understand which privileges each client receives, we have to examine the roles of each person within the context of the game. Of course, the spectator client has no direct access to control any of the data within the database, but only the ability to view it in a specifically organized way, designed for them. The coaches can make their own calls on the outcome of certain plays, however, the umpire has the final deciding vote in each outcome. Therefore, the umpire has the most direct control on data writing privileges into the database. This means the umpire and the coaches will require unique identifiers within the database permissions to decide which client surpasses the other. The coaches have direct control over the team rosters. These must be initially entered into the database prior to the game; new clients can be easily added, and will of course start with empty data sets. Existing clients can be confirmed, or removed, from the database. Data backup is possible, such that any “deleted” client will have their data saved, but will not be updated for the game. Since each player will be filling multiple roles at different times, the roster itself can dynamically change, in the sense that the current roles being filled by each player can be displayed. This means the umpire, spectators, and the other coach, will always have immediate access to the players and the roles they are currently fulfilling. 2.2 Figure 3 outlines this privilege design, illustrating each client’s privileges and data flow priorities. For special cases, such as pitching limits per player, each pitcher will have an updated pitch counter each time they fill the role. When the pitch count is reached, the next pitcher (with available pitches) must be chosen by the coach, after the database alerts the software that the pitch count is now at a maximum. This pitch count check must validate within the database before each pitch occurs. 
2.2 Figure 3: Database Access Privileges The method of database implementation presents a few possible choices. For more direct accessibility, the database can be stored as a physical server at each baseball field. This provides easier control and management for the teams, as well as quicker access times. Having the database directly available allows the team to manage the data in a more convenient way, allowing them to copy, store, and delete data within the physical device, including storing the data on separate servers, or migrating the data to new systems. Another option is storing the database server within a cloud system, provided by an online service. 2.2 Figure 4 outlines the access path required to communicate with a cloud database. The biggest online provider of database cloud servers is Amazon. Specifically, they offer multiple database cloud services for more complex systems, as well as a simple design for more basic systems. Both systems are designed around MySQL. These options would definitely be cheaper, however provide more issues with bandwidth control (internet access) as well as direct control by the coaches. In a system design based entirely around access times, relying entirely on network bandwidth for data transactions with the database could have negative side effects, such as increasing read and write times from the mobile device applications to cloud querying. Some other added bonuses include data reliability, as Amazon has more data redundancy than a physical server system maintained by the baseball teams could ever have. Additionally, Amazon provides efficient ways of managing costs; they only charge for actual data usage and bandwidth usage per month. 
2.2 Figure 4: Database Cloud Computing Directory: seniordesign -> fa2010sp2011 seniordesign -> Hvac control and Feedback System 0 Group 2 Steve Jones Mathew Arcuri Elroy Ashtian, Jr seniordesign -> Group 5 Spr-Sum 2011 seniordesign -> Senior Design II paper seniordesign -> Remote Touchscreen-Controlled Defense Turret Senior Design Documentation Courtney Mann, Brad Clymer, Szu-yu Huang Group 11 seniordesign -> Flight Performance Data Logging System seniordesign -> Amphibious vehicle seniordesign -> T-100 Watch Dog (Autonomous Security Vehicle) seniordesign -> Ehvac: Wireless Modular Multi-Zone hvac controller Group b javier Arias Ryan Kastovich Genaro Moore Michael Trampler Download 471.88 Kb. Share with your friends:
|