SelCtlDB

NW Data Centric home   home   [about]   downloads  

Current loctn: about > devel process

Development Process

Technical Documentation

A relatively formal development process was used. This results in a comprehensive set of high-level technical documentation. Nearly all that documentation is provided in the technical documentation downloads for the database. The level of described detail far exceeds the typical poor documentation of non-profit databases. This should make it much easier for 3d party developers to work with the system when needed.

Data Model

The SelCtlDB data model is designed to avoid problems seen repeatedly in nonprofit databases over several years of experience. We attempted to create a single, generic data model providing a close fit to basic needs of nearly any non-profit without major modifications.

We find accurate data model diagrams essential for use and continued development of a database. We use specialized data modelling software (CASE*Studio) during development to ensure this accuracy. The software allows generation of scripts to automatically create data tables in a variety of database packages including Oracle, MySQL, PostgreSQL, Sybase, Access, SQL*Server. When database tables are generated in this fashion, the data model will be a very accurate representation of the resulting database. Furthermore, this software offers the required capacities at an affordable price - making it possible for other developers to work with the data model using similar techniques.

Incremental Client Project Development

The overall database developed in incremental stages during work for several clients. The first development provided a relatively basic implementation. Later stages added more complete development of the full system.

Although open source tools would have been preferred, Microsoft Access was a good choice for these first clients. Since all conceptual and high-level design of data model and application modules had been performed in a fashion that was independent of platform choices, MS-Access was used for these first implementations

Select ControlClass Modules

The basic prinicple of the Select Control class modules was developed from analysis of data quality problems present in nearly every nonprofit database we encountered over several years. Two problems were prevelent and troubling:

  1. Duplicate records
  2. Poor report flexibility

Problem: Duplicate Records

Nearly all nonprofit databases we encountered in our early work had substantial problems with multiple representations of the same individual. This typically arises from inadequate searches for preexisting records during data entry processes.

Furthermore, detection and elimination of unwanted duplicates is inherently complex. Automated deduplication provides only a partial solution. Final cleanup almost always requires time-intensive manual review and editing.

Because removal of duplicate records is difficult and time-consuming, a prevention-based approach was adopted. The SelCtlDB encourages thorough searches for pre-existing records as a standard part of data entry processes.

Problem: Poor Report Flexibility

Nonprofit databases in our experience (perhaps with the prominent exception of ebase) frequently have problems related to selection of records included in reports.

For example, a typical MS-Access report specifies the record selection criteria as a component of the report. Many nonprofit databases contain very large numbers of similar reports that differ only in the set of records represented. Compounding the problem, these reports are often poorly named, making it very difficult to understand which report should be used for a particular need, or which ones are obsolete. These situations often become totally unmanagable for users. Our clients often engage a developer simply to define a report similar to others already provided - differing only in representing a different set of records.

To eliminate the need for developer attention or duplication of reports for record selection changes, the SelCtlDB provides capacity to dynamically define selection criteria to any pre-defined report.

Problem Solution

The problems outlined above both relate to record selection capacities of the database. To avoid duplicate records, the ability to search and review similar records is needed. To avoid accumulation of an unmanagable number of reports, the ability to construct and apply varied selection criteria to existing reports is needed.

To solve these problems, a set of programming tools was constructed to facilitate these tasks. The Select Control VisualBasic class modules used in the database provide this function. Now implemented in VisualBasic within an MS-Access version of the database, the same concepts may be implemented using languages such as Perl, Python, etc.