Overview of Design Methodology

This Database Application Development Methodology was developed specifically designed for applications that are supported by databases. It will not work for generic software development.

Assumptions of the Database Application Development Methodology:

  1. Business processes are well-designed
  2. Documents are known
  3. Tasks are known
  4. System boundary is known
  5. One database schema unifying all views can be designed

Documents: Anything that is input to, or output from, the applications that run on the database.
Tasks: The processing that takes place, using those input documents and generating those output documents, while appropriately updating the database in the process.

Number 5, above, is one of the biggest impediments to successfully creating a database schema. The reasons for the difficulties are generally related to company politics and a lack of a single cohesive goal within the organization.

Overall Software Process

  1. Business Process (re-)design
  2. Analysis
  3. Specification
  4. Design
  5. Implementation
  6. Testing
  7. Operation
  8. Maintenance

Only the bold items in the list above are considered part of the scope of this discussion. These items are unique for database methodology.

In contrast to the Software Development Process, the methodology discussed here is Data First, not Process First. The Processes are introduced only after the Data is correctly structured.

Given an Information Flow Diagram, how does one go about creating a specification of a database? When the database discipline was young, people talked about this process as the “art” of database specification/design.

The instructor developed this methodology over the years to remove some of the art and introduce some mechanical steps.

Four Stages of the Methodology

1. Analysis

Output is the Information Flow Diagram

2. Specification

A. First step is to create an EER Diagram representing the data, then
B. Outlining the Tasks (or applications) that need to run on the database represented by the EER Diagram.

3. Design

A. Translate the EER Diagram to a Relational Schema, then
B. Convert the tasks that represent the actions that need to happen in the EER Diagram and represented them with Abstract Code.

4. Implementation

A. Use something like MySQL to create the Relational Database.
B. PHP Code is used with embedded SQL to rep