-------------------------------------------------------------------------------
San Francisco Green Party - Database Redesign
-------------------------------------------------------------------------------

INTRODUCTION
The San Francisco Green Party has maintained a database of contact and financial information for several year. The database is currently implemented in FileMaker Pro, with several files (the FMP analog for tables) attempting to track volunteers, donors, donations, and other types of meta information.

USE OF THE DATABASE
The current FileMaker Pro database is used to track people, donations, and volunteer offers.

THE CURRENT SYSTEM
The current database consists of three FileMaker Pro files (tables, in other databases) that exist on one of the Macintosh computers. The main file tracks personal information, and attempts to track a great quantity of meta-data. The second file attempts to track donations, while the third attempts to track volunteer information.

The current database has become unwieldy to use. The interface does not take advantage of the relational capability of the software. Many fields are duplicates (across tables/files as well as in the same table/file). There is very little validation, field names are not consistent, and the field ordering is random. These problems are the result of ad-hoc modification of the data structure by any individual with access to the database.

REQUIREMENTS
The goal of this effort is to create a relatively comprehensive data plan for the party, resulting in a new database that better suits the party's needs. The specific requirements are:

I. Data Requirements:
   The database must track the following items:
	A. People
	B. Requests to volunteer, with volunteer skills
	C. Sustainer sign-ups
	D. Contact occurrences (phone, in-person, meeting attendance, etc)
	E. Contact Preferences
	F. Donation occurrences (including sustainer ocurrences)
II. Access and Priveleges:
    The database must provide different levels of user priveleges. Som users must be able to add, modify, and delete all manner of records, while others (e.g. ad-hoc volunteers) should be restricted in what they can do. We have identified several access levels:
	A. Admin users:
		1. Data definition
		2. Record add/modify/delete (all tables)
		3. View & query data (all tables)
	B. Power users:
		1. Record add/modify/delete (all tables)
		2. View & query data (all tables)
	C. Ad-hoc users:
		1. Record add/modify/delete (some tables or fields)
		2. View & query data (some tables)
		NOTE: There will likely be several subtypes of Ad-hoc users. One type may need to have rights to one set of tables, while anothre group may need to have rights to another set. These rights may overlap at certain points (a common "people" table, for instance).
	D. Restricted users:
		1. View & query data: (some tables)
III. Concurrence and Locking:
     There must be a provision for multi-client use of the database over the network. The office currently has three functioning computers, and we expect to obtain more. There will likely be situations where we have several volunteers doing simultaneous data entry. As such, the system implemented must allow for concurrent multi-user access with some record-locking provision.

	 FileMaker Pro allows for multi-user access over TCP/IP. We should investigate its concurrency and locking features as well.

IV. Backup:
	This data is the lifeblood of the party. We must design and implement a backup strategy that preserves the data at fairly regular intervals.

V. Data Import:
   There will likely be several areas where data will need to be imported into the new database. We may, for example, want to import volunteer signups from the SFGP web site. We may also want to import donation occurrences or sustainer signups from another application. We must provide and document a reliable way to import data and resolve the problem of duplicate records that will inevitably arise from such an operation.
   
   FileMaker Pro conains a fairly robust data import mechanism. We will need to develop and document processes for each type of data import that the party needs to do.

VI. Design Record and Alteration Process:
	Databases often require alterations of their schema to account for changing business needs. There must be provisions and processes in place to accomodate these changing needs while maintaing a good data design and disciplined data practices.
	
	Very few people should have priveleges sufficient to add fields, tables/files, or formats. Any changes to the data structure should be made by a member of the IT working group.
	
	Any database implementation must result in a data design that can be kept and maintained should we eventually decide to move to another system. The format of this design (XML, scripts, etc) should be determined prior to implementing the new database.