Due to the amount of data traffic being tracked per team, player, and game, a design implementation using FileMaker Pro will allow easy organization of data for the system, as well as simplified user support for the coaches and players. A key component to data management in this software, is managing data accesses for the devices, as well as allowing the data to be easily accessible for analysis by the teams. Among available database software tools, FileMaker Pro focuses on both of these aspects. Since the database tools must allow two types of access, this means both types must be customized. Fortunately, they run independently of each other, allowing direct template-style viewing properties while the database itself is being streamlined and modified by the device software. A coach, for example, might attempt to view the database values directly, that is, via the database software. For this type of access, a new UI within the database software must be supported, and usable by the coaches.
Based on the data organization used by baseball staticians, player stats can be split into five categories: General, Batting, Pitching, Baserunning, and Fielding. When applying these values to database fields, the database structure itself can ignore these categories. They are only required for organizing data for personal analysis and design efficiency. The fields themselves can be added, removed, or completely ignored (unused). Since the device applications will have specific functions calling each used database field, the stats stored in the database must be pre-determined. This means the coaches cannot change the stats they wish to record dynamically, unless the option to do so has been pre-programmed into the database and application.
Data must be divided among specific categories, and organizing the groups is a crucial aspect to maintaining acceptable performance. To reduce complexity, each team will have their own database entry, each player will have a table entry, and each statistic will have a field entry. 3.4 Figure 1 shows the detailed layout of the database structure. The statistical variables are stored as modifiable integer, float, and string fields, as per the requirements of each individual statistic. Since all statistics are dependant to a specific player, each player will be stored as identical tables within the team database. If players have statistical discrepancies, such as some players not pitching, then these unused statistical values will remain empty. Since fields and tables can be dynamically added and removed within a database, this creates an optimal scenario for the data storage, as players can be easily removed or added to any team. The fields (statistic types) will never be removed or added, since these are all based on official baseball statistic types. Each player will have all of the statistic types available to them. If an existing player becomes a pitcher, for example, the previously ‘empty’ pitching statistics are already available to be accessed.
3.4 Figure 1: Structural database outline
The database itself will require a server system to run the software, as well as store data. A typical concern when it comes to storing the statistics is the size of the data. Typically databases can consume several gigabytes of storage, but for storing basic stats of a few baseball teams, the storage will end up being less than 1 Gigabyte. This implies any standard average-sized hard drive will do the job, and of course data compression can be used to compensate for any space shortages. Unfortunately, this would considerably slow down data read/write times within the database, so should be avoided. Considering the amount of clients performing simultaneous access to the database, this means the server will be under constant disk reads/writes while moving data. This problem can be alleviated by increasing system RAM, more simultaneous activities will require more memory. Additionally, frequent access require more constant hard disk activity. Optimizing hard disk read/write speeds will improve response time performance. In the server system controlling the database, the hard disk being used is the most important factor. Some statistics require mathematical calculations, mostly focused around averages. Batting averages, pitching averages, run averages, for example. While these values must be consistently updated for every player, the calculations are so small and infrequent, processor power is a minimal concern. Of course, responding to user accesses require process handling, but any modern dual-core processor will be able to handle the task
3.4.2 Data Structures
The database will need to be split into two pieces: live data and archived data. Depending on what information is being accessed, the database will need to respond in a unique way. While a game is in progress, the database must track live data. Additionally, the database must track global data for analysis and feedback purposes. For interfacing purposes, this category will be called Team Records. This data must be updated during and after the completion of a game, to reflect the most accurate data. This kind of data is always valuable, and can be required at any time, during or after a game, and based on the needs of the data, it will always need to be the most recent values. Based on how the live data is updating, the archived data can easily increment and alter values as data changes. Also, there are events occurring during the game which may not be of value in the live data (batting/pitching averages, for example) which will need to updated in the archived data immediately.
Since all of the team records are stored within a single database entry, each player must be identified according to their team. Additionally, this means player and team statistic comparisons can be quickly calculated, as all team statistics are located within the same database. The Team indicator is vital to scoring a team’s overall statistics, since the only valid identifier for the team as a whole is the Team field. At first this seems tedious, but relying on multiple databases per team puts more load on the database server, and consequentially lowers reaction times and increases stress on the system. With a constant flow of data activity, it’s optimal to keep all activity within as few databases as possible. A text-based identifier simplifies the sorting process. 3.4.2 Figure 1 shows the layout design for team-based statistics. The graphical design serves only an organizational purpose for database layout and as a direct-access interface. The variables themselves are simply stored as variables within fields, in each table entry. Each player will receive their own entry as shown, with all of the optional fields. The values within the team database will be updated concurrently with game data, during a baseball game. This data exists permanently within the database, adding and removing players occurs dynamically, causing a team record to exist as long as the team physically does. 3.4.2 Figure 2 depicts an example player of the Knights team, depicting career-long team-based summed statistics. As the player participates in games, his career statistics are updated in the team database. Values labeled as “averages” are calculated based on an official baseball formula, and stored in the appropriate field. The equations for these average values were discussed previously in this document.
3.4.2 Figure 1: Team Database Structure
3.4.2 Figure 2: Team Database In-use
The second utilized database is the live game data. Since this data is only employed during a game, it can be deleted or stored elsewhere after the game. For record-keeping purposes, this data will be backed up after each game. Each new game will replace data being actively used within the live database. Backups can be accessed later for analysis by the coaches and players. Live data requires the most constant flow of activity, as the baseball game has constantly changing factors which must be reflected within the database. Fortunately, the live database will require data fields. This means there is less data to maintain and update. Data occurring during the game that must be stored in the archived data, but is not necessary to the game itself, can be stored directly to the archive and bypass the live database entirely. Using this separation, the live database’s size, and load, can be minimalized. Due to the live database’s increased activity during a game, optimizing it as much as possible is a priority, to increase performance for the clients. Live data will not be analyzed as thoroughly as overall data. However, creating a user interface (as used in the archived data) is inherently seamless, so it can be implemented. Coaches and players will want to study their performance each game, so the data must be accessible. Some data, such as little league restrictions (pitch counts and ball counts) must be tracked, but not archived. This data must be checked each time before a pitch to ensure that no restrictions have been violated. 3.4.2 Figure 3 depicts the design layout for the live game data. Similar to the team record, this database additionally counts game-specific data such as the pitching counter, as per little league rules. Sorting this data independently of team records, though both records share most statistics, allows for the most-accessed data to be readily and easily available, as well as ignoring inaccurate career-based statistics from the team record, which use the same statistical variable name. This prevents career data from interfering with live game data, and reduces stress on the server since it does not have to perform the task of sorting the data types.
3.4.2 Figure 3: Game Database Structure
3.4.3 Database Functions and Variables
The table below (3.4.3 Table 1) shows the variables initially being stored in the database.
General statistics included
|
Batting statistics included
|
Pitching statistics included
|
Games Started (GS)
Games Behind (GB)
Games Played (G)
|
Single Plays (OneB)
Double Plays (TwoB)
Triple Plays (ThreeB)
At Bats (AB)
Batting Average (BA)
Runs (R)
Total Bases (TB)
Hits (H)
Strikeouts (K)
Home Runs (HR)
|
Base On Balls (BB)
Batters Faced (BF)
Earned Runs (ER)
Earned Runs Average (ERA)
Hits Allowed (HA)
Innings Pitched (IP)
Home Runs Allowed (HRA)
Strikeouts (K3)
Run Average (RA)
Balk (BK)
|
3.4.3 Table 1: Database variables.
Share with your friends: |
