Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
1 INTEGRATED DATA BASE DEMONSTRATION BACKGROUND At the 1985 Woods Hole Workshop, participants investigated ways of developing a prototype integrated data base demonstration. Workshop participants recommended that a special demonstration prototype project team be formed to develop the concept during the next year.1 The project team was subsequently organized and held its first meeting in October 1985. The objectives of the demonstration prototype project team were to design and implement a demonstration prototype of the integrated data base (IDB) that would be available as a research tool for three to five years and could be used by the committee, project participants, and their representatives to (1) gain a better understanding of how the IDB will be used in the future building process and the resulting requirements that the IDB will have to satisfy, and (2) investigate alternative technical solutions to IDB implementation problems of linking data files and data bases of multiple computer systems through a common (integrated) data base for use throughout the life cycle of a facility. At the second meeting of the project team in December 1985, it was decided that an initial prototype IDB demonstration should be available at the 1986 Woods Hole Workshop. The initial prototype was planned as a tool for both the invited participants at the workshop and for the demonstration prototype project team. The concept was to use the initial prototype at the workshop to walk through a typical scenario in the building process so that workshop participants could use that example to address specific questions relative to the IDB, as well as to future enhancements of the prototype. The team would seek feedback from workshop participants on questions such as: Is this the kind of prototype required to resolve the issues that now delay the introduction of the IDB technology in the building process? What kinds of changes are desired in the prototype over the coming year? What resources are needed to extend the prototype further, and how will those resources be obtained? 1Members of the demonstration prototype project team are listed in Appendix 3.
CONFIGURATION OF THE PROTOTYPE IDB DEMONSTRATION The configuration of the prototype IDB demonstration is planned as the first phase of a multi-Phased approach to the implementation of the prototype. The central processor is a DEC MicroVAX II, with a 5 megabyte MOS memory plus three 71 megabyte fixed Winchester disk drives with controller, a VT240 terminal and an LA100 printer/terminal. The operating system is MicroVMS, configured for eight concurrent users. The permanent prototype configuration will include the Tektronix high resolution color graphics terminal, Model 4125 (the terminal used at the 1986 Woods Hole Workshop was a borrowed Tektronix 4111). An IBM PC/AT equipped with Enhanced Graphics Adapter (EGA) was also used during the demonstration. The Data Base Management System (DBMS) was ORACLE, and the applications software included AUTOCAD, CDS, STRUDL and STAAD III. Vendors generously donated the equipment and software required for the prototype, or loaned it to the Building Research Board for an extended period. The configuration was assembled and integrated by demonstration prototype project team members Paul Scarponcini and Jim Greetham at McDonnell Douglas AEC Systems Company in St. Louis, Missouri. Building design data were prepared by Gary Seibert of the U.S. Army Corps of Engineers, Savannah District; he also played a key role in preparing the initial data model. Other data were prepared by team members David Kalish and Malcolm McCullough of Autodesk and Jack Enrico of Bechtel Power Company. Jim Anderson, consultant, CDC Information Analysis Services, provided expert advice on the design of the conceptual data model for the initial prototype using the NIAM data modeling method (see Chapter 3). Richard Zitzmann, a consultant to the Building Research Board, provided the overall project team management. SCENARIO At the workshop the prototype was used by team members to walk through a typical sequence of tasks that occur between the design and construction phases of the building cycle. To keep the implementation of this initial prototype to a manageable size, the team decided to restrict the effort to the various tasks and activities involved in the design and construction of a wood truss. The building design selected for the case study was a mobilization administration and supply building for which the Corps of Engineers had an existing design. Although this snapshot of the building process is just a small portion of the entire cycle and addresses only the structural sub- system, the team found that the lessons learned from this effort can be extended to other subsystems and phases and can go a long way toward
addressing issues related to global data modeling and desired charac- teristics of the IDB. Future research efforts could broaden the scope of investigation. During the demonstration, Fred Kitchens of the U.S. Army Corps of Engineers described the steps that the client would follow in establishing requirements for the building, including preparation of Form 1391, a standard form of the Corps of Engineers that is used to initiate a construction project. Data required for subsequent tasks in the scenario were stored on the MicroVAX using ORACLE. Mr. Kitchens also explained the owner's view of data throughout the whole building process. Malcolm McCullough, the architect for the demonstration, explained how he used the owner's requirements to drive his activities, which involved the use of AUTOCAD to generate the architect's view of the building floor plan and a cross section of the roof. These data were stored in the demonstration IDB for use by the structural engineer. Gary Seibert, the structural engineer for the demonstration, walked through the steps of the design task in detail. He retrieved the architect's view from the demonstration IDB, generated a design, analyzed it using STAAD III, and accessed a simulated on-line external data base for physical properties of wood materials. He then prepared a drawing of the wood truss design that was loaded into the demon- stration IDB. Jack Enrico played the role of general contractor. He used requirements and design data on the wood truss to prepare the work breakdown and the contractual requirements for the fabricator/subcon- tractor. The resulting data were included in the demonstration IDB. The fabricator role was played by Jim Greetham who worked through the task in detail, retrieving data from the demonstration IDB, preparing a detailed fabricator's view using CDS, and performing structural analyses using STRUDL. His results also were stored in the demonstration IDB. At one point in the scenario, the flexibility of the IDB concept was illustrated by showing how the client could make a change in requirements. The other participants demonstrated how the new data could be accessed directly, and how design and contract changes can be made quickly. Throughout the demonstration, the progression of the scenario was illustrated using a projected graphic display from the Tektronix 4111 terminal. Figure 1-1 shows the prototype configuration in the lower left-hand corner, the flow of the scenario at the top, including the current step being presented and the data base functions required to support that step. The latter information was given in the lower right-hand corner of the graphic display which also illustrates the general notion that the IDB consists of data distributed among external, transition, and application data bases.
II i an 1 I CHI J 9 ft 4J O o a tt .0 3 I â¢o u a o o
CONCEPTUAL DATA MODEL The structural engineer's task and the fabricator's task were presented in detail during the demonstration, as summarized in the above scenario description. To ensure that the demonstration IDB contained the necessary data entities and attributes and that the data base was populated with the data required for these two tasks, Gary Seibert and Paul Scarponcini, aided by Jim Anderson, performed detailed task analyses and initiated the design of the IDB conceptual data model as the prototype IDB demonstration configuration was being assembled prior to the workshop. Two goals of the demonstration were to explain how the tasks were analyzed and the data modeling methodology used. That work was used as a starting point for the task analysis working group (see Chapter 2) and the data modeling working group (see Chapter 3). INTEGRATOR At the 1985 Woods Hole Workshop, the concept of the integrator was introduced. The integrator represents a composite of the functions necessary to support an IDB in a distributed, heterogeneous hardware and software environment. There have been a significant number of research projects in the computer industry and at universities that have addressed at least some of the technical issues that derive from achieving an integrated data base in a distributed, heterogeneous environment.2 These issues include data integrity, query processing, catalogue management, concurrency, fragmentation, transparency, recovery, and others. In treating these issues, a lexicon of terms has been developed by researchers to describe requisite data base functions; for example, they include "global data management," "distributed transaction management," and "global-local subqueries." The integrator concept was defined at the 1985 workshop without regard to specific implementation of functions, the data base manage- ment system to be used, or even the potential segmentation of issues as other researchers may have done. Instead, a conceptual structure was established for the integrator, consisting of five components: 1. The Director. Includes the data dictionary, information on where data are stored, file formats, access authorization, current status, specific physical implementation information, 2. The Accessor. Determines access strategies, creates files, removes files, adds data, deletes and retrieves data, 3. The Translator. Contains knowledge of requirements for different views of data, formats of sources and targets, and performs conversions, 2A list of sample projects is given in Appendix 4.
10 4. The Communicator. Provides data transfer between hardware and systems, and 5. The Administrator. Ensures security of data (controls read, update, delete), integrity, consistency, currency; provides for concurrency, recovery, backup; and enforces inclusion and exclusion rules. During the detailed demonstration of the structural engineer and fabricator tasks, an explanation was given about the components of the integrator necessary to support the two tasks. In essence, the structural engineer task illustrated a store-data operation while the fabricator task illustrated an operation of retrieving data from the IDB for analysis. Although this initial prototype was not capable of executing most functions of the integrator, the demonstration was designed to show the sequential steps of the integrator for the two tasks that were demon- strated in detail. At the workshop, a working group was asked to prepare a plan for further developing the concept of integrator that could form the basis for a future implementation of integrator functionality (see Chapter 4). LESSONS LEARNED Following the demonstration, the project team conducted a panel discussion that addressed the lessons learned by the team while implementing the prototype IDB demonstration. A summary of key points follows: 1. Not only was the equipment configuration a prototype, but the project team was a prototype of an organization necessary to implement an IDB. As a result, the team went through a learning experience on the implementation process itself. 2. Although it was learned that use of a thorough, well-structured methodology was essential to design the logical data model, it did not seem that there was any one method that was significantly better than any other well-established method for use with the building process. 3. The lack of a formal project organization, similar to a project for a software development, was an impediment for the volunteer IDB demonstration prototype project team. Progress was hindered because of the dependence on voluntary resources. 4. Even though the prototype IDB demonstration effort was limited in scope intentionally, it became obvious that the volume of data for the building process is large; some effort is required to make wise decisions on exactly what data to include in the transition data base over time. However, it may be that this problem will be less severe in the future as new, automatic ways to capture data are discovered. 5. The question of the proper level of detail for the data model was debated. Some team members advocated a high-level model. Others
11 held that data modeling is a never-ending, evolutionary process, and that the model should be developed in bite-sized pieces. 6. Future prototype IDB demonstration efforts should include the facility management phase of the building life cycle where there are many existing management problems for the owner, and where large cost savings are likely to be achieved.
