Using BSAdv

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.

This document describes all of the possible data that can be entered into the BSAdv database. It is possible that your unit has decided not to enter certain types of data in your copy of the database. This is not only allowed, but encouraged. If your unit wants to ensure that certain Scout contact information does not get entered into your database, you will not see them in your entry forms. If you have any questions about how your unit has configured your copy of BSAdv, contact the person reponsible in your unit.
There are two major types of data: Unit data and BSA data. Unit data is specific to your unit: information about your Scouts, adult leaders and your activities. BSA data is related to rank advancement requirements and merit badge requirements. BSA data is defined by the BSA and is useful in BSAdv to assist tracking the Scouts' accomplishments in these areas. People in your unit will routinely enter unit data, and will use the BSA data to follow progress toward the advancement goals. The BSA data will be changed infrequently, only when BSA changes the requirements. BSA data will likely be updated only by those people in your unit who manage the unit web site.
Similarly, there are two ways to interact with the database: read and write. Writing to the database includes entering personal information about the Scouts and adults, and entering data relating to the unit activities. BSAdv uses various fill-in forms for data entry. The use of forms makes it easier to understand the relationship between different parts of the database. Reading from the database is done by reports, which read the database and create human-readable or computer-readable output. This is the way most people will observe the database contents. Reports include individual Scout advancement reports, unit roster, and many more.

The Database

Unit Data

Unit data falls into the following categories:

Scouts - information about the Scout himself. Includes name, address, phone numbers, email address, birth date, patrol membership, positions of responsibility. All of this data is optional, so a unit can choose to not have any information on the Troop website that identifies a Scout, except for one name. This name can be a nickname, identification number or whatever the unit chooses to uniquely identify each Scout. This identification is needed for database editors to identify the Scout, when entering Scout-specific advancement data and when reporting the results. It is important to remember that you must enter a Scout into the database before you can record advancement completion for him.
Events - information about unit activities, including when, where, what was accomplished, who participated, etc. All of the Scout advancement information is located in this part of the database.
Adults - information about the adult leaders themselves. Includes name, address, phone numbers, email address, adult leader training, etc. Unit activities require two or more adult supervisors, so we need a list of leaders to track their participation. This same list is used to identify the parent and/or guardians of the Scouts.
Accounts - deposits and withdrawls to individual Scout and adult accounts. These can be categorized and totaled for various activities and purposes.
Awards - dates that Scouts have earned awards, that the awards were purchased and that the awards were presented to Scouts. Currently, this is not connected to the completion of the requirements of the award, which are tracked in events.

BSA Data

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.

Advancement Ranks - names and dates of ranks and their requirements.
Merit Badges - names and dates of merit badges and their requirements.

Why we keep old requirements

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.

Configuration Data

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.

Links between Database Tables

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:

Starting with a list of all Scouts, choose the Scout and look at a list of his activities.
Starting with a list of all unit activities, choose the activity and look at a list of Scout attendence.

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.

Events

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.

Sourceforge.net

Thanks to Sourceforge.net for hosting our project.