Building database-backed Web applications: process and issues.

In this article, the process of implementing database-backed Web applications from initial planning to final implementation and beyond will be explored. Both technical and "people" issues will be addressed, including choosing hardware and database platforms; selection of development tools and approaches; making decisions on the allocation of time, personnel, and equipment; and assigning data and system administration tasks. (1) It is necessary to consider these points, even if a project seems simple, to ensure that no issues have been overlooked. Carefully thinking through all aspects beforehand can minimize the number of problems one will encounter later.

**********

There is a growing body of literature on database-backed Web pages, both on general topics and specific platforms. (2) The library press is also beginning to publish in this area, including articles by Antleman, Mischo and Schlembach, Kiehl, Summers, and Westman. (3) There are several clear advantages of using a database rather than relying solely on static HTML pages: (1) it allows one to focus on inputting rather than formatting data; (2) it reduces the time required to maintain Web pages; and (3) it permits the reuse of information in a variety of situations and to serve a multiplicity purposes. However, when implementing this technology, one needs to undertake careful planning and weigh the costs versus the benefits. One will need to address a number of issues and make a number of decisions. Knowing what to expect will help to ensure success.

* Planning

Deciding What You Want

When beginning, it is important to define the desired goal of the project and determine whether a database is the appropriate tool for that goal. Database-backed applications generally:

** use structured data where output via different parameters such as subject or material type is desired;

** enable searching of the data by various parameters;

** manage constantly changing data; and

** allow the reuse of information in different contexts and pages.

Get Everybody on Board

Once it is determined that a database is the appropriate tool for the job, it is necessary to get buy-in from two areas, administration and staff, before proceeding. Database-backed Web projects can consume significant staffing resources, may require a substantial financial investment in the short-run, and involve ongoing support in the long run. It is therefore critical that the library administration understands and fully supports the project. To obtain this understanding and support, answers must be provided to a number of questions:

1. What will be the benefit of this project? Answers can include saving time, providing better access to information, or allowing for more efficient workflow.

2. What will the costs be in terms of money and staff time? What will need to be dropped to do this? What new hardware, software, and personnel will be needed? Can it be done with existing infrastructure?

3. How is this project to be accomplished? What is the timeframe for its implementation? What are the steps to be taken and when should each step be completed? What expertise is needed? Does such expertise exist in-house or can it be acquired?

4. How much time and effort will it take to maintain this application? How much data inputting and updating will be involved? Will it be worth the investment? What subsequent programming and technical resources will be needed?

It is also important to identify the persons who will fill various roles in the project. Note that one person may perform more than one role. Necessary functions include:

** Project coordinator--the person who oversees the project and makes sure things stay on-track

** Data users--the people who will help define the data and the functionality to be included in the application

** Designer--the person who finds out what data are needed and then creates the required data models

** Database administrator--the person who implements the data model and who administers the database management system (often the same person as the designer)

** Developer/programmer--the person who programs the application

** Testers--users who test the application (4)

The project coordinator, by having the answers to these questions when approaching the library administration, can provide the administration with the information needed to make an informed decision. Having these answers makes certain that the coordinator has thought the issues through, thus ensuring the project's success.

Staff members also need to support the project. Since the new system will involve changes in their work, they need to understand the reasons for the changes and to support them. In particular, they need to be shown how this new application will make their work easier. By involving staff in the application from the beginning, they will have an investment in its implementation.

Think Big, Start Small

When starting the project, one should think big but start small. Thinking big means looking at the project from a larger perspective. What other uses might there be for the proposed database? Are there other types of information that could benefit from being made available in such a manner? If so, what are the relationships to the project under consideration? It is necessary to ask these sorts of questions to help assure that the project will work well with future products that the library might develop as well as permitting easy integration of new features into the proposed application at a later time.

Starting small means undertaking a project that realistically can be accomplished. This type of project may involve many people and will require planning, coordination, and communication. Staff will need to allocate time for evaluating, purchasing, and installing the hardware and software required to create the application. Starting small allows staff to define issues and to learn how to use and develop the tools and techniques needed for successful implementation. It also provides an idea of ongoing maintenance requirements and allows for gradual integration of the final product into the library environment.

Note that, while thinking big ensures the product will be flexible enough to support future development, it is important not to create false or unrealistic expectations. Getting people excited about possibilities that cannot be fulfilled can create frustration that could endanger the acceptance of the current application and possibly engender resistance to any new projects.

Once the project is defined, the project coordinator should establish a timeline to provide structure to the development process. This timeline should list each task to be done and indicate the order in which the tasks should be accomplished. It should also include realistic target dates with the names of those responsible for each task's completion. This schedule is valuable in making important time, money, and personnel allocations, as well as helping to keep the project on track.

* Defining the System

The next step is to define the application. As Greenspun points out, this requires one to:

take [the] publishing idea ... and apply three standards steps:

1. Develop a data model--Define what information is going to be stored and how it should be represented

2. Develop a collection of legal transactions on that model, e.g., inserts and updates

3. Come up with a set of Web forms that let the user build up to one of those transactions. (5)

* Develop a Data Model

Data modeling is perhaps …