|BSAdv Project on SourceForge|
| BSAdv Home Page
| Release Notes
| Using BSAdv
| Youth Protection
Developers: | To Do List | Database Tables | Extending BSAdv | Database Consistency
This is a users guide to the database. The intended audience are those that will enter data for their unit. This guide will not discuss programming details. There is other documentation for that.
To enter data, you need to know a little about what type of data you can enter, and what limits you have on entering it.
Unit data falls into the following categories:
This data is defined by the Boy Scouts of America (BSA) and documents the requirements for rank advancement and merit badges. The BSA updates the requirements occasionally. When they do, the BSAdv team will code the new requirements into the correct format and allow the unit web site manager to download an update. The update will add the new requirements to the BSAdv database. The database has been designed to not require deletion of obsolete requirements. New requirements exist alongside the older ones and allow Scouts that have started work with the older requirements to continue with those, if BSA allows. There should be no reason for a unit to update this data other than normal BSA updates.
In addition to current rank advancement and merit badge requirements, BSAdv retains the previous, outdated versions also. The reason is to allow Scouts who have started work using the previous requirements to continue with those. Simultaneously, Scouts just starting work should use the new requirements. The BSAdv database needs to maintain both old and new versions to track Scouts on both old and new tracks.
How many of these should we maintain? That is a difficult question to answer. Since Scouts can generally span ages of 11 to almost 18, a unit may have some Scouts completing merit badge requirements that they started seven years ago. BSAdv must maintain requirements for the past seven (or more) years. A good target is ten years. In the initial release, BSAdv will implement BSA requirements that are ten years old and less. We will maintain this initial set of advancement and merit badge data during future BSAdv revisions. New requirements will be added, but none will be deleted. This will keep the units' data consistent at all times in the future.
Certain features of BSAdv can be configured through the back-end. This is the only part of BSAdv that uses the back-end. Everything else uses the front-end.
Without going into tremendous detail on database design, it is good practice to have each piece of data exist in only one place in the database, and to refer to that data from other places. As a result, BSAdv uses tables that associate data in one table to data in another table. For example: Many Scouts may participate in an activity. It would be redundant and error-prone to enter the same detailed activity data in a list of activities for each Scout that participated. Instead, it is better to have a list of Scouts, a second list of activities, and a third list that links Scouts to activities. This third list simply consists of pointers to both the Scouts list and the activities list.
BSAdv uses this multi-table approach with pointers that associate data from different tables. As a result, the database can be confusing to deal with directly. BSAdv uses these pointers to create web forms that are much easier to understand than the underlying data. It also means that you can use these pointers from two different starting points. For example, a Scout's attendence at an activity can be reviewed and edited by:
When you enter a Scouts' participation in an activity, you create one of the pointers betwen the Scouts tables and the activities table. If you delete a Scouts' participation, you delete the pointer. BSAdv manages the database so the user does not need to completely understand what goes on behind the software curtain.
So far, we have talked about activities. In BSAdv, we separate activities into two parts: Events and Deeds. Events are the simplest: where and when the event occurred. Deeds are more complicated and includes everything that occurred at an event, including rank advancement, nights camped, miles hiked, etc. An event can, and usually does, have more than one deed that occurred at that event. On the other hand, every deed must be associated with one, and only one, event. Scout and adult participation is recorded for deeds, not for events.
Thanks to Sourceforge.net for hosting our project.