Database lifecycle

Designing a database is usually done as part of a larger development project. A database on its own is not much good - you also need the user interface at the very least. From this observation, you might conclude that the database can simply be treated as another system component, and that a standard development methodology can be applied. There are some specific aspects of database design that bring this into question, however:

• No other system components use the same conceptual framework, and therefore the database needs specific attention. The identification of entities and attributes, and the definition of their relationships is not required in any other part of the system. It requires specific skills and techniques, and should not be artificially dependent on other parts of the process.

• The database is a logically fundamental component on which everything else depends The user interface and other system components rely on the database structure being correct. If that structure needs correction at an advanced stage of the development, many other components will need to be checked and possibly corrected as well. The database needs to be prioritised in the development in contrast to other components.

• It is difficult to test a partially constructed database Several current approaches to software development are based on the principle of iterative delivery of prototypes. Because the database presents a model of the business environment with static relationships between entities, opportunities to test parts in isolation are limited.

Connolly and Begg (p. 264) offer this graphical summary of the development process to show where the database development activity is concentrated:

In a real development project, each of the activities represented by boxes in the diagram might have its own documentation and sign-off procedures. In a one-person project many of these are not required. In this module, we are primarily concerned with the activities in the lighter box labelled Database design. Before looking in more detail at the three phases of database design, however, there are some useful observations to make about this breakdown of the development process.

Those activities that appear above the Database design box are primarily concerned with developing an understanding of the project requirements. It is during the Requirements analysis activity that user interviews will be conducted to identify entities, attributes relationships and constraints.

The four activities in the lower right-hand corner are those that take place once the development is complete. Implementation in this context refers to the task of creating a live version of the development system. Data conversion and loading is where the data required for the operation of the new system is retrieved from its current location and any modifications are done before storing in the new database. Testing in this context means ensuring that the live system works as expected, that is to say, in comparison with the development system. It does not refer to the usual testing that is done throughout the development process.

Application design and Prototyping refer to the other development activities required to produce the user interface and other components.

A specific activity for DBMS selection appears on the diagram because there may be special requirements that arise out of the Database design process.

All of these activities are described in greater detail in chapter 10 of Connolly and Begg. If you are up to date on the rest of the work for the module, this would be a good time to read through that chapter. Because you are working individually on small artificial projects, many of these activities will seem to have little point just now; however, a good appreciation of how the work of designing the database fits in with the rest of a development project is vital in a team situation. Remember that in third year, you may be involved in a group project: these additional activities will have more relevance at that time.