14.7 Centralized Database Management Systems

Whichever conceptual model or database management system is adopted, the use of a central database management system has a number of advantages and some costs compared to the commonly employed special purpose datafiles. A datafile consists of a set of records arranged and defined for a single application system. Relational information between items in a record or between records is not explicitly described or available to other application systems. For example, a file of project activity durations and scheduled times might be assembled and manipulated by a project scheduling system. This datafile would not necessarily be available to the accounting system or to corporate planners.

A centralized DBM has several advantages over such stand-alone systems:

For the purpose of project management, the issue of improved availability is particularly important. Most application programs create and own particular datafiles in the sense that information is difficult to obtain directly for other applications. Common problems in attempting to transfer data between such special purpose files are missing data items, unusable formats, and unknown formats.

As an example, suppose that the Purchasing Department keeps records of equipment rental costs on each project underway. This data is arranged so that payment of invoices can be handled expeditiously and project accounts are properly debited. The records are arranged by individual suppliers for this purpose. These records might not be particularly useful for the purpose of preparing cost estimates since:

An alternative arrangement might be to separately record equipment rental costs in (1) the Purchasing Department Records, (2) the Cost Estimating Division, and (3) the Company warehouse. While these multiple databases might each be designed for the individual use, they represent considerable redundancy and could easily result in inconsistencies as prices change over time. With a central DBM, desired views for each of these three users could be developed from a single database of equipment costs.

A manager need not conclude from this discussion that initiating a formal database will be a panacea. Life is never so simple. Installing and maintaining databases is a costly and time consuming endeavor. A single database is particularly vulnerable to equipment failure. Moreover, a central database system may be so expensive and cumbersome that it becomes ineffective; we will discuss some possibilities for transferring information between databases in a later section. But lack of good information and manual information management can also be expensive.

One might also contrast the operation of a formal, computerized database with that of a manual filing system. For the equipment supplier example cited above, an experienced purchasing clerk might be able to immediately find the lowest cost supplier of a particular piece of equipment. Making this identification might well occur in spite of the formal organization of the records by supplier organization. The experienced clerk will have his (or her) own subjective, conceptual model of the available information. This subjective model can be remarkably powerful. Unfortunately, the mass of information required, the continuing introduction of new employees, and the need for consistency on large projects make such manual systems less effective and reliable.

14.8 Databases and Applications Programs

The usefulness of a database organization is particularly evident in integrated design or management environments. In these systems, numerous applications programs share a common store of information. Data is drawn from the central database as needed by individual programs. Information requests are typically performed by including pre-defined function calls to the database management system within an application program. Results from one program are stored in the database and can be used by subsequent programs without specialized translation routines. Additionally, a user interface usually exists by which a project manager can directly make queries to the database. Figure 14-6 illustrates the role of an integrated database in this regard as the central data store.

Figure 14-6  Illustration of an Integrated Applications System

An architectural system for design can provide an example of an integrated system. First, a database can serve the role of storing a library of information on standard architectural features and component properties. These standard components can be called from the database library and introduced into a new design. The database can also store the description of a new design, such as the number, type and location of individual building components. The design itself can be composed using an interactive graphics program. This program would have the capability to store a new or modified design in the database. A graphics program typically has the capability to compose numerous, two or three dimensional views of a design, to introduce shading (to represent shadows and provide greater realism to a perspective), and to allow editing (including moving, replicating, or sizing individual components). Once a design is completed and its description stored in a database, numerous analysis programs can be applied, such as:

Production information can also be obtained from the integrated system, such as:

The advantage of an integrated system of this sort is that each program need only be designed to communicate with a single database. Accomplishing appropriate transformations of data between each pair of programs would be much more difficult. Moreover, as new applications are required, they can be added into an integrated system without extensive modifications to existing programs. For example, a library of specifications language or a program for joint design might be included in the design system described above. Similarly, a construction planning and cost estimating system might also be added.

The use of integrated systems with open access to a database is not common for construction activities at the current time. Typically, commercial systems have a closed architecture with simple datafiles or a "captive," inaccessible database management system. However, the benefits of an open architecture with an accessible database are considerable as new programs and requirements become available over time.

Example 14-5: An Integrated System Design

As an example, Figure 14-7 illustrates the computer aided engineering (CAE) system envisioned for the knowledge and information-intensive construction industry of the future. In this system, comprehensive engineering and "business" databases support different functions throughout the life time of a project. The construction phase itself includes overlapping design and construction functions. During this construction phase, computer aided design (CAD) and computer aided manufacturing (CAM) aids are available to the project manager. Databases recording the "as-built" geometry and specifications of a facility as well as the subsequent history can be particularly useful during the use and maintenance life cycle phase of the facility. As changes or repairs are needed, plans for the facility can be accessed from the database.

Figure 14-7  Computer Aided Engineering in the Construction Industry
(Reprinted with permission from from Y. Ohaski and M. Mukimo, "Computer-Aided Engineering in the Construction Industry," Engineering with Computers, Vol. 1, no. 2, 1985.

14.9 Information Transfer and Flow

The previous sections outlined the characteristics of a computerized database. In an overabundance of optimism or enthusiasm, it might be tempting to conclude that all information pertaining to a project might be stored in a single database. This has never been achieved and is both unlikely to occur and undesirable in itself. Among the difficulties of such excessive centralization are:

In addition to these problems, there will always be a set of untidy information which cannot be easily defined or formalized to the extent necessary for storage in a database.

While a single database may be undesirable, it is also apparent that it is desirable to structure independent application systems or databases so that measurement information need only be manually recorded once and communication between the database might exist. Consider the following examples illustrating the desirability of communication between independent application systems or databases. While some progress has occurred, the level of integration and existing mechanisms for information flow in project management is fairly primitive. By and large, information flow relies primarily on talking, written texts of reports and specifications and drawings.

Example 14-6: Time Cards

Time card information of labor is used to determine the amount which employees are to be paid and to provide records of work performed by activity. In many firms, the system of payroll accounts and the database of project management accounts (i.e., expenditure by activity) are maintained independently. As a result, the information available from time cards is often recorded twice in mutually incompatible formats. This repetition increases costs and the possibility of transcription errors. The use of a preprocessor system to check for errors and inconsistencies and to format the information from each card for the various systems involved is likely to be a significant improvement (Figure 14-8). Alternatively, a communications facility between two databases of payroll and project management accounts might be developed.

Figure 14-8  Application of an Input Pre-processor

Example 14-7: Final Cost Estimation, Scheduling and Monitoring

Many firms maintain essentially independent systems for final cost estimation and project activity scheduling and monitoring. As a result, the detailed breakdown of the project into specific job related activities must be completely re-done for scheduling and monitoring. By providing a means of rolling-over or transferring the final cost estimate, some of this expensive and time-consuming planning effort could be avoided.

Example 14-8: Design Representation

In many areas of engineering design, the use of computer analysis tools applied to facility models has become prevalent and remarkably effective. However, these computer-based facility models are often separately developed or encoded by each firm involved in the design process. Thus, the architect, structural engineer, mechanical engineer, steel fabricator, construction manager and others might all have separate computer-based representations of a facility. Communication by means of reproduced facility plans and prose specifications is traditional among these groups. While transfer of this information in a form suitable for direct computer processing is difficult, it offers obvious advantages in avoiding repetition of work, delays and transcription errors. A de facto standard for transfer of geometric information emerged with the dominance of the AUTOCAD design system in the A/E/C industry. Information transfer was accomplished by copying AUTOCAD files from user to user, including uses on construction sites to visualize the design. More flexible and extensive standards for design information transfer also exist, such as the Industry Foundation Classes (IFC) standard developed by the International Alliance for Interoperability (See http://www.iai-international.org/iai_international/) and the "Fully Integrated and Automated Project Processes" developed by FIATECH (see http://www.fiatech.org/)

14.10 References

1. Au, T., C. Hendrickson and A. Pasquale, "Introduction of a Relational Database Within a Cost Estimating System," Transportation Research Record 1050, pp. 57-62, 1986.
2. Bosserman, B.E. and M.E. Ford, "Development of Computerized Specifications," ASCE Journal of Construction Engineering and Management, Vol. 110, No. CO3, 1984, pp. 375-384.
3. Date, C.J., An Introduction to Database Systems, 3rd Ed., Addison-Wesley, 1981.
4. Kim, W., "Relational Database Systems," ACM Computing Surveys, Vol. 11, No. 3, 1979, pp. 185-211.
5. Mitchell, William J., Computer Aided Architectural Design, Van Nostrand Reinhold Co., New York, 1977.
6. Vieceli, A.M., "Communication and Coding of Computerized Construction Project Information," Unpublished MS Thesis, Department of Civil Engineering, Carnegie Mellon University, Pittsburgh, PA, 1984.
7. Wilkinson, R.W., "Computerized Specifications on a Small Project," ASCE Journal of Construction Engineering and Management, Vol. 110, No. CO3, 1984, PP. 337-345.
8. Latimer, Dewitt and Chris Hendrickson, “Digital Archival of Construction Project Information,” Proceedings of the International Symposium on Automation and Robotics for Construction, 2002."