for the Degree of Master in Computer Science in the Department of Computer Science. Mississippi State ... Professor of. Associate Professor of Computer.
DESIGN OF A RELATIONAL DATABASE FOR THE U. S. ARMY CORPS OF ENGINEERS PROGRAMS AND PROJECTS MANAGEMENT INFORMATION SYSTEM
By Barbara Jean Cuevas
A Directed Project Report Submitted to the Faculty of Mississippi State University in Partial Fulfillment of the Requirements for the Degree of Master in Computer Science in the Department of Computer Science Mississippi State, Mississippi December 1996
DESIGN OF A RELATIONAL DATABASE FOR THE U. S. ARMY CORPS OF ENGINEERS PROGRAMS AND PROJECTS MANAGEMENT INFORMATION SYSTEM
By Barbara Jean Cuevas
Approved:
______________________________ Julia E. Hodges Professor of Computer Science Department (Director of Project)
______________________________ Bradley D. Carter Professor of Computer Science Department (Member of Committee)
______________________________ Thomas Philip Professor of Computer Science Department (Member of Committee)
______________________________ Susan Bridges Associate Professor of Computer Science (Graduate Coordinator of the Department of Computer Science)
TABLE OF CONTENTS
Page LIST OF FIGURES ………………………………………………………………..…
ii
CHAPTER I.
INTRODUCTION …………………………………………………………
1
Background …………………………………………………………….… Project Definition ……………………………………………….………… Objective ………………………………………………………………….. Development Environment ………………………………………….…...
1 3 3 4
LOGICAL DATA MODEL DESIGN AND PHYSICAL DATABASE DEVELOPMENT…………………………………….……
6
Design Objectives ……………………………………………….….……. Identification of Entities ………………………………………….……… Identification of Relationships ………………………………….………. Identification of Primary Keys ………………………………………….. Identification of Foreign Keys …………………………………….….…. Validate Data Model Through Normalization …………………..…..… Building the Relational Database Schema from The Data Model .… Role and Security Implementation ………………………………….…. Creation of Table Triggers, Functions and Procedures ………….…. Design of Test Plan ………………………………………………………
6 6 10 11 11 12 12 13 13 14
SUMMARY ………………………………………………………….…….
16
Analysis of Project Objectives ……………………………………….….
16
IV.
BIBLIOGRAPHY …………………………….…………………..……….
19
V.
APPENDIX A. PROJECT CONTRACT …………………………………………….
20
II.
III.
-i-
LIST OF FIGURES
FIGURE
Page
1. Project level data entities …………………………………………..……………7 2. Task level entities ………………………………………………………………...8 3. Version data for Project Management Plan ……………………………………9
-ii-
CHAPTER I INTRODUCTION
Background As part of the 1984 Information System Modernization Program (ISMP), the U. S. Army Corps of Engineers recognized the need to provide standardized, integrated information systems to support management of Corps projects and their allocated resources. The Programs and Projects Management Information System (PROMIS) is one of these ISMP projects. The history of PROMIS software development has been turbulent. There have been three separate starts of the project. The second start of the project resulted in the development of a story-board prototype, Concept Design Document (CDD). This “paper executable” provides an in-depth analysis of the graphical-user interface and has become the primary source of functional requirements for PROMIS. A ‘C’ prototype, developed to prove the functional requirements of the CDD, was viewed by some management personnel as a potential PROMIS deployment package. The decision to deploy the C prototype would have been a major mistake. The database supporting the prototype was a ad hoc database in which entities and attributes were added as needed by
-1-
-2-
the software developers. This potential mistake was circumvented upon the halting of development by Congress in April 1993. Upon resumption of project development, an agreement was made with management to drop the C prototype and develop PROMIS within certain guidelines. The controlling constraints placed on the project related to time and cost. The deployment date for PROMIS was administratively set by agreement with Congress. This “setting in stone” of the deployment date proved to be a difficult goal to meet in the software development of PROMIS. PROMIS will provide Corps managers with an integrated tool with which to plan, apply resources, and schedule the projects which they must administer under their jurisdiction. There are three primary missions of the Corps. The first is the civil works project which can be authorized for the building of locks and dams, for navigation, for flood control, or for coastal or inland waterways maintenance. The second is the military project which could include construction at a military site or installation. The last is the Hazardous, Toxic, and Radiological Waste (HTRW) which spans a wide spectrum of projects that pertain to cleanup of hazardous wastes. Each type of project is governed by a different set of laws and regulations and has its own unique data requirements. The development process of the PROMIS software and database is supported by a Field Project Advisory Team (FPAT) . This committee is comprised of program and project managers from various Corps of Engineers districts and divisions. These individuals, along with the PROMIS project manager, who is
-3-
herself a civil engineer with civil works project management experience, were the key to the development of functional requirements for the software system as well as the data model and data base.
Project Definition PROMIS as defined in the CDD will provide the project manager and his/her project team with a set of tools to enable them to create and maintain a project plan and monitor execution of that plan. There are several major information areas that will be stored and maintained in the PROMIS database. These are project , task, resource (cost), schedule, and descriptive comments information. One of the major goals of the ISMP projects is to provide a single source of data entry. The project manager and his/her project team will be that single source of data entry for the required project management plan. This plan is the basis for reports required by higher authority which include division and headquarters as well as Department of Defense and Congress.
Objective The objective of this directed project was to design a relational data model for the development of the PROMIS database and related database objects, functions, and procedures to support the functional requirements set forth in the CDD.
-4-
The Logic Works data model design tool ERwin was employed in the design of the data model for PROMIS. ERwin provided a substantial tool set for the development and documentation for the project. The data model methodology used was the Corps standard, IDEF1X (Bruce 1992.). This methodology is supported by ERwin. Several target database systems are supported by this tool. Oracle Version 7 is one of these supported database systems. I utilized this functionality of ERwin by generating SQL scripts for the creation of the database tables and fields. This included the generation of scripts to create foreign key constraints and primary and alternate indexes.
Development Environment The PROMIS software was developed in Ada in a client/server environment. The system will execute on any Microsoft Windows operating system. This includes MS Windows 3.1 and 3.11, MS Windows NT and MS Windows 95. This, of course, meant that the system must be operational on both 16bit and 32bit operating systems. The project was, therefore, forced to employ the Win32s windows API. The PROMIS database was developed utilizing the Oracle Version 7 relational database management system located on a regional Sun Micro-computer running a version of the UNIX operating system. Due to the unavailability of a Pro-Ada pre-compiler for the Rational Rose VADS Ada compiler chosen for development (Windows NT), the Data
-5-
Direct Intersolve Open Database Connectivity (ODBC) drivers for Oracle version 7 were used for development.
CHAPTER II LOGICAL DATA MODEL DESIGN AND PHYSICAL DATABASE DEVELOPMENT
Design Objectives The objective of any data modeling project is to produce a logical data model that accurately represents the information requirement of the business process; is consistent in the naming, definition and documentation of the objects; provides sharable data entities for other systems (such as the Corps of Engineers Financial Management Information System (CEFMS)); and is flexible to accommodate changes that will most certainly occur during the development and maintenance phase of the project (Fleming and von Halle 1989). This effort was followed by the implementation of the logical data model in a physical data base schema.
Identification of Entities A pool of potential data entities were collected from a previous data model developed by a functional project manager and the Conceptual Design Document and a draft Systems Requirement Specification prepared by the
-66
-7-
contracted software developers. Candidate entities were categorized and defined for potential creation of data entities. This work was done with the assistance of functional users. The data model diagram and data dictionary were provided to these users as frequently as possible to provide feedback on the adequacy of the data model definitions and object identifications. The users were also very helpful in the identification of the relationships between these entities. One of the major data classification areas of the model is project level entities. The project is the major identification item in the PROMIS system. The data related to the project comprised entities that help to define the project for the project team and for reporting to higher echelons. Potential entities included comments, identification of project team, categories of a project to include civil works project, military project, and HTRW project specific data and any other related data entities required to further identify the specific project type. Other entities that were identified were customer (the organization sponsoring the project) and the location of the project. Figure 1 shows a partial data model for the project level entities identified during the design phase of the data model. Another major classification area of the data model is the Project Management Plan (PMP) entities. This area includes all entities that help to define the scope, cost and schedule of the project. The Corps of Engineers has identified standard scope for the three identified project types. This scope is
-8-
Figure 1 Project level data entities
defined as the Work Breakdown Structure (WBS) of the project. The standard WBS structure is identified in templates that are used by the project manager to develop his/her own WBS to accomplish the purpose of the project. The WBS structure is identified in the PMP as tasks or as products of the task. These tasks are depicted in a hierarchical manner by the identification of parentage. The other basic data entities of the PMP include the cost entity for resource estimates and the schedule entity. The cost and schedule entities are children of the task which is part of the WBS. A recursive relationship for the task defines the hierarchical structure of the WBS. The standard WBS and hierarchical structure are inherited from the template providing the project manager with a foundation of the scope of his/her project. The basic model for the task information is shown in figure 2.
-9-
Figure 2 Task level entities
A unique requirement of the PROMIS system is to provide the user with the capability to “version” his/her PMP based on scope, cost, and time changes and conditional what-if scenarios. This “versioning” concept requires that the project level data be divided into non-version project data (that data that would not change in the execution of the project) and version data (changes of scope, cost or schedule that may occur during the life of the project). Some task level information could also be unchangeable across multiple versions of a project. An example of this data is the original WBS code and name from the standard template. A diagram depicting this model is shown in figure 3.
-10-
Figure 3 Version Data for Project Management Plan
Note that the non-version entities of project, task and non-version comments are also displayed in figure 3.
Identification of Entity Relationships The identification of relationships between the entities was aided by interviews with the functional users and review of the CDD. In most instances, the identified relationships were ultimately built into foreign key constraints between the parent and child entities. The identification of these relationships
-11-
provided additional definition to the entities being created and the data that supported the entity. As the ER diagram was developed with the ERwin tool, the relationships identified business rules of the data model and the business process being modeled. In some instances, the identification of a relationship would require the creation of new entities. An example of this is the NAS_Activity_Schedule* * (NAS stands for Network Analysis System). Upon identifying a successor/predecessor relationship from the Work_Version* table, the entity Network_Link* was developed as a child of NAS_Activity_Schedule* to resolve the relationship.
Identification of Primary Keys The primary keys were determined by reviewing the definition of each entity and creating a pool of potential primary key attributes. The potential keys were reviewed to insure that the resultant primary key is unique and minimal (Date 1986). In many cases, an attribute was created to assist in the creation of the primary key. An example of this was the Resource_Estimate*, for which a unique number was assigned to the Resource_Estimate*.
Identification of Foreign Keys Identification of foreign keys was simplified by defining relationships according to the type of relationship - whether identifying or non-identifying
*
see figure 3.
-12-
relationship. Identifying relationships are relationships in which the primary key of the parent becomes part of the primary key of the child, or the parent key helps to identify the child. Non-identifying relationships indicate that the parent’s primary key becomes part of the non-key attributes of the child; even though a part of the parent’s primary key may be in the child’s primary key, the parent’s total key does not help to identify the child entity (Bruce 1992).
Validate Data Model Through Normalization Normalization rules were applied to the diagram to insure desirable entity decomposition and identification. To apply normalization principles, each entity and its associated attributes were examined for structural redundancies or inconsistencies in accordance with the identified normalization rules. This examination included the first, second, third and Boyce/Codd normal forms (Date 1986; Fleming and von Halle 1989).
Building the Relational Database Schema From the Data Model The translation of the data model created for PROMIS into a relational database schema was made easier by the use of the ERwin data modeling tool. The data model was fully defined as to primary, foreign, and non-key attributes for the entities. The relationships between the entities had been fully identified and defined. The ERwin tool provided a mechanism for entering the attribute data types and lengths. The tool also provided functionality for the identification
-13-
of specific tablespace to be created for the system. Physical schema names were entered and table sizes computed for the creation of the physical database. ERwin also provided a method through which relationships and primary and alternate keys could be created through table constraints and indexes.
Role and Security Implementation Various user roles were identified by functional representatives and the CDD. Major roles identified were the project manager (PM), technical manager (TM), and system administrator (SA). Other roles have been identified but have not been given any specific behavior in PROMIS. Until these other roles have been fully defined as to the functions they will perform in PROMIS, the only roles that the system will recognize are the PM, TM, and SA. The specific abilities of each role has been identified in the CDD and will be enabled with an application role. Roles are enabled during a user session made the PROMIS application. The users will be given read-only access to the Oracle database when they access the database by any other means other than the PROMIS client (Oracle 1992).
Creation of Table Triggers, Functions and Procedures During the creation of the Oracle database and development of the PROMIS client software, certain functions were identified that would be best implemented through database table triggers, functions or procedures. An
-14-
example of a database table trigger is the insert trigger on the project table. This trigger will create a task to act as the root of the hierarchical “tree” for the WBS structure when a new project is inserted. This trigger also queries the financial system (CEFMS) to retrieve required financial links to the accounting system. Functions were created to return task identification codes and information such as fiscal year or the currently assigned official version of a project. Procedures were created to generate required key fields such as comment numbers, version numbers, task numbers, customer number (for new customers), or template numbers (for customized templates). Procedures were written to assist in the locking and unlocking of a project version when a user opens the version for write through the PROMIS client (Feuersttain 1995).
Design of Test Plan The test plan for the PROMIS data model and database involved the use of informal inspections of the structure of the data entities, attributes, primary keys, and relationships enforced by foreign key constraints. These inspections were performed on an individual basis by the PROMIS development team. Problems identified in these inspection reviews were discussed and resolved in open meetings of the entire team. Further testing of the data model and resultant database involved unit and integration testing scheduled for the delivered software. Testing performed by the software team, independent
-15-
software testers and the FPAT highlighted errors that were identified and corrected in the data model and database.
CHAPTER III SUMMARY
Analysis of Project Objectives The development of the PROMIS system has been successful in that a deployable version of the PROMIS database and software executable have been developed and has undergone strenuous testing. As in all software projects, continuous change requests and problem identifications mandate that the data model be constantly reviewed and revised. Specific change procedures are followed for potential modifications to the Data Model and Data Dictionary. This precedes any changes made to the Oracle database structure. This procedure insures that any change does not invalidate the data model. As a review of the database schema and underlying data model, an analysis was made to insure compatibility with the graphical user interface as presented in the Systems Requirement Specification. The result was a database “Mapping” document which highlighted the interrelationship between the database and the PROMIS client. This review resulted in many corrective actions to be made to the data model, data dictionary, and finally the Oracle database structure.
-16-
-17-
The creation of alternate indexes for the database tables is also an ongoing operation. As the performance of the PROMIS software is monitored and the query statements reviewed, new alternate indexes will be recommended and implemented through the data model to the database structure. The review of the database has also highlighted some foreign key constraints that were unnecessary to the system and created problems in queries or updated of the tables. Security for a database accessed by client software presented serious issues for consideration and resolution during the evolution of the project. These issues were partially resolved by utilizing the Oracle role capabilities that are enabled only while a user is accessing the PROMIS database through the PROMIS application. The database developed from the ERwin data model implemented business rules identified by entity relationships through the establishment of foreign key constraints. Other business rules were initiated by database table triggers and check constraints placed on fields within specific tables. During the design and implementation of many activities to be performed by the PROMIS system, a determination was made that these activities would be best implemented within the Oracle database through functions and procedures. These functions and procedures were developed using the PL/SQL programming sub-language of Oracle Version 7. The activities supported in this
-18-
manner involved project version locking and unlocking, price level computation and reporting, and the retrieval of system generated primary keys for new projects and tasks. As in all database design projects, the data model and the resultant database schema evolved based on changes to functional requirements, internal changes made to meet changing technologies, and changes required by other automation projects that have data requirements from the software project. PROMIS will be fielded to approximately 50 Corps districts and 6 divisions. Each district will maintain its own Oracle database; yet using the powerful query tools of Oracle Version 7, the data contained in each of these 50 databases can be accessible to the Corps divisions and headquarters. The Corps of Engineers will have a standardized Programs and Projects Management Information System.
REFERENCES
Bruce, Thomas A. 1992. Designing quality databases with IDEF1X information models. New York, NY: Dorset House.
Date, C. J. 1986. An introduction to database systems. Reading, MA: Addison-Wesley.
Feuerstein, Steven. 1995. Oracle PL/SQL. Sepastopol, CA: O’Reilly and Associates, Inc.
Fleming, Candace C., and Barbara von Halle. 1989. Handbook of relational database design. Reading, MA: Addison-Wesley.
Oracle Corporation. 1992. Oracle7 server application developer’s guide. Redwood City, CA: Oracle Corporation. .
-19-
APPENDIX A PROJECT CONTRACT
-20-
-21-
PROPOSED ABSTRACT FOR A DIRECTED PROJECT CS 8083
Barbara Jean Cuevas
June 10, 1996
Major Professor and Project Director
Committee Members
: _________________________________ Dr. Julia Hodges
: __________________________________ Dr. Bradley Carter
: __________________________________ Dr. Thomas Philip
Student
: ___________________________________ Barbara Jean Cuevas
-22-
Project Description The U. S. Army Corps of Engineers has contracted with the Waterways Experiment Station to design and develop a Programs and Projects Management Information System (PROMIS). PROMIS will be a client/server application that will provide integrated project management tools to the Corps’ Districts to assist in the identification, planning, execution, and monitoring of work. The PROMIS application will be required to interrelate with other systems developed by the Corps.
These systems are the Corps of Engineers Financial Management
System (CEFMS), the Real Estate Management Information System (REMIS), and the Resident Management System (RMS).
PROMIS will also replace
upward reporting stovepipes for the project management community. PROMIS will provide a project manager with a set of tools to collect and maintain project data for scope of work, cost of work and the schedule of work. The scope will be in the form of a work breakdown structure that contains the tasks/activities identified to accomplish the objectives of the project. PROMIS will allow the user to define the resources required to accomplish each task/activity.
Schedule data will be provided to the project by interfaces to
Commercial Off the Shelf (COTS) Network Analysis Systems. Objectives The objectives of this project are: (1) to design and model a relational database for the Programs and Projects Management Information System to be implemented with the Oracle RDBMS, (2) develop security functions for the client/server application and implement these through the Oracle RDBMS, (3)
-23-
develop database table triggers to implement business rules and enforce data integrity constraints, and (4) to develop database procedures and functions to perform required server functions. Constraints and Considerations PROMIS must conform to a corporate data model developed during the design of the financial system. Due to schedule constraints, many database operations will be accomplished by the execution of procedures, functions and database table triggers on the server. Another consideration in the development of the PROMIS data model and database is the decision that no two Corps information systems will perform the same function. This will require that PROMIS perform some financial functions within the financial system. Project Deliverables The project deliverables will be include: 1) Software Requirements Specification 2) Data Model 3) Data Dictionary 4) Database Description 5) Database Procedures/Functions Design Document 6) Source Code for Database Procedures/Functions and Integrity Triggers 7) Test Plan
