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.
3 DATA MODELING INTRODUCTION The working group on data modeling focused on the modeling of building project data at the semantic, or conceptual, level. At this level of abstraction, an enterprise can be described directly and naturally in terms of the objects, attributes, and relationships important to the enterprise. By comparison, the data model that evolved during the 1985 Woods Hole Workshop identified the basic data types, relationships, and attributes that a building data base would have to support and that could be used to express the contents of the semantic model. Thus, in an overall framework, the previous data model fits between the semantic model developed this year and a physical data base implementation. This working group on data modeling was aided materially by the limited semantic model that had been developed for the prototype integrated data base demonstration. Through a critique of the prototype model, the group was able to identify key missing concepts, as well as to generalize existing concepts to higher levels of abstraction. In the following sections, the relevant results of the 1985 Woods Hole Workshop are summarized, the current conceptual model is assessed, the process and methods of modeling are discussed, and a strategy for implementation of the data model is presented. Members of the working group were Len Simutis (chair), Jim Anderson, Per Christiansson, Bob Fulton, Kent Reed, and Dave Skar. RESULTS OF THE 1985 WOODS HOLE WORKSHOP At the 1985 Woods Hole Workshop a working group on conceptual modeling constructed what it called a conceptual model of the integrated data base, representing it as a finite state machine (FSM). This representation allowed the group to express clearly the idea that the current state of a project is reflected in the current state of its corresponding FSM-data space. The various user views of the data base are then represented by transition functions that can examine and modify this state. Data consistency is enforced within the transition functions themselves rather than by any external process. 29
30 The group developed a data model that described the characteristics that data may possess and defined the relationships and operations allowed between and on the data, respectively. Treated in this model were data and meta data, as well as operations, meta operations and meta-data operations. Finally, the group developed several examples of how a user view can be extracted from the data base according to the conceptual model. It should be noted that, in its work, the working group indicated only the kind of semantic information that was needed and did not try to develop a supporting semantic model. ASSESSMENT OF CONCEPTUAL MODEL In assessing the IDB conceptual model developed to date in the Woods Hole Workshops, the group identified several areas that the model needs to address, or which require clarification. Most fundamentally, the model views the building as the sum of its parts. The design, assembly, and operation of the building are processes that depend on information about the building parts and spaces. For the conceptual model to be sufficiently robust, it was concluded that the model must include part-to-part relationships as data attributes. The building parts themselves must contain informa- tion on revisions made during design, construction, or operation since these changes will have cascading effects on other aspects of the building process. Further, the concept of shape, as used in the model, needs to be expanded to incorporate a full description of part geometry. This information was viewed as vital to address the issue of connectivity between parts so that assembled components could be identified and analyzed. Also, connectivity of parts may be used as one way of defining spaces. Rather than giving names to a particular space, thus complicating nomenclature and leading to ambiguity or error, the geometry that gives the location and extent of a space can be deter- mined by identification of its interconnected components. Parts have three-dimensional shapes, and the parts, when connected, identify three-dimensional spaces. The group considered how best to incorporate architectural and construction drawings into the conceptual model. For some, the drawings could be seen as graphic representations of building design and construction--a sequence of increasingly detailed information about building components required for construction and building operation. For others, drawings were simply another way of providing a report of a building's "state" of architectural design and construction as it evolved and developed over time. While the notion of drawings as important summary documents in their own right is critical to many computer-aided design (CAD) systems currently in operation, the group concluded that drawings are simply another way of representing or reconfiguring the relationships among elements in the IDB. In short, a drawing is not different conceptually
31 than a tabular summary from the data base; it is another kind of report. THE PROCESS FOR DEVELOPING DATA MODELS A structured approach to the development of data models in support of administrative data bases has evolved over the previous decade. The first steps in this approach, contained within the box in Figure 3-1, are (1) definition and analysis of the tasks that must be supported by the data base, (2) analysis of the information flows that are required in these tasks, and (3) definition of the elements of a semantic model that will support this information flow. ExIstIng SemantIc Concepts About the BuIldIng Process FIGURE 3-1 The process for developing a data model.
32 Unlike administrative data, buildings have been the subject of conceptualizations for centuries. A large body of semantic concepts already exists, and a modification of the above modeling process is proposed. As shown in Figure 3-1, the existing high level concepts and derived conceptual models are refined and integrated into a draft semantic model. This model encapsulates agreements in areas such as shape and structural grammars, building part descriptions, building process activity descriptions, and so on. The draft model is then tested against the task and information flow analyses described previously, and modifications are made as needed. It should be apparent that desirable characteristics for a semantic model include extensibility, since it is a certainty that the model will be neither complete nor immutable. As new tasks are defined and analyzed, new features or modifications to existing features in the semantic model will be required. The methodology chosen for developing the model should support this and other characteristics such as simplicity, since the model must be understandable if it is to be useful, and consistency, since the model must provide meaningful and unambiguous responses to queries. DATA MODELING METHODOLOGIES Bringing about a successful integration of information depends largely on business functions and the size and complexity of the organization. Information integration requires rigorous, analytical techniques, backed up by powerful tools and a methodology that oversees the total life cycle of an entire project. Methodologies providing these capabilities have been, or are being, developed for different types of data models that capture semantic information including the entity-relationship model, the extended relational model, the functional data model, the semantic association model, the semantic data model, and the semantic hierarchical model. It is not clear which, if any, of these models provides the best fit to building project information. Therefore, a particular methodology-- NIAM (Nijssen Information Analysis Methodology)--was selected by the working group based primarily on the availability to the group of tools and information. This decision will almost certainly be revisited as more research results become available about the nature of building project information. The Methodology Used on the Prototype IDB Demonstration The NIAM methodology describes the relationships of objects and the roles of these objects to support the views for the prototype IDB. NIAM uses a three schema/view architecture. The first view is the Semantic Information Model. This view uses the identified information flows to develop the information structure model. The Semantic Infor- mation Model identifies all information elements, relevant semantics, and constraints required for information integrity.
33 The diagram for the Semantic Information Model, Figure 3-2, is made up of (1) objects, (2) roles, and (3) uniqueness constraints. Objects take on two forms: the non-lexical object type (NOLOT) and the lexical object type (LOT). Roles that form the relationship between two NOLOTS are ideas, while the roles that connect a NOLOT to a LOT form a bridge OBJECTS (LOT) ROLES Role of Object 1 Role of Object 2 NOLOT 1 ROLE OF NOLOT 1 ROLE OF NOLOT 2 NOLOT1 2 BRIDGE OR REFERENCE ROLES NOLOT 1 ROLE OF NOLOT 1 ROLE OF LOT1 UNIQUENESS CONSTRAINT 1 TO MANY 1 TO 1 MANY TO MANY MANY TO 1 FIGURE 3-2 The semantic information model.
34 or reference. The uniqueness constraint defines the cardinality of the objects role in a relationship, or joint relationship. After developing all the relationships for the Semantic Information Model, a Neutral Data Model can be defined. The Neutral Data Model specifies record types and their elements, and the behavioral con- straints on the elements of each record type. The NIAM methodology starts with the Functional Model and the information flows that connect the functions to create the Functional Flow Model. The Functional Flow Model, Semantic Information Model, and Neutral Data Model are combined with a definition of the detailed logic of each of the lowest level components of the Functional Flow Model to produce a Logical Process Model for the information system. From the resulting models, one or more prototypes are built based on the requirements model. The validation prototype is performed with- out hardware and software restrictions. These validation prototypes are used to validate the contents of the models and identify necessary modifications. The final outcome of the NIAM methodology is a design specification that can then be used for building the sections that will be supported by a heterogeneous environment. The Semantic Information Model is also known as a conceptual model. From the conceptual model the logical data base schemas, the program views for each of the physical data bases, and the logical internal schema for the computerized parts of the information system can be determined. VALIDATION PROTOTYPE IMPLEMENTATION The work to date on the IDB has provided good insight into the potential of a future IDB to support the building process. The prototype's focus, however, is on the storage and management of data associated with the structural design and construction process. The data models appear to represent adequately the entities at that stage of the building process. It is recommended that a second prototype IDB implementation be carried out to validate selected areas of data modeling associated with the maintenance and operation phase of a building. The specific focus of the application should be based on the recommendations of the task analysis working group (see Chapter 2), which considered data such as those associated with the operation and maintenance of the building, its contents, and its subsequent modification or rehabilitation. The goal of this validation prototype system should be to both validate data model issues and to provide an illustrative example to help a federal agency take the next step toward development of a usable prototype IDB.
35 Scope of the Validation Prototype System The development of a prototype system can be a major undertaking. The following discussion is to focus attention on the key data modeling thrusts to be addressed. Figure 3-3 shows a functional view of the system from the perspective of data modeling. At the top are the various types of data to be managed for the user shown at the bottom. The user is provided a set of tools and menus to facilitate the query and use of the data. The data base is composed of a conceptual model DATA TYPE1 DATA TYPE 2 DATA TYPE 3 INTEGRATOR DATA MODEL REFERENCE VIEW1 REFERENCE VIEW 2 CONCEPTUAL A MODEL ) ( EXTERNAL \VIEW1 EXTERNAL 1 VIEW 2 S MENU OPTIONS QUERY PROCESSOR MODEL VALIDATION PROTOTYPE USER/ APPLICATION FIGURE 3-3 Data model view of the IDB.
36 together with various specialized views of the data. A set of software utilities serves as the integrator between the data model and the various data types. As the figure indicates, the system should concentrate .on data model issues rather than on displays of application tasks. While the other parts of the system may be useful for other purposes, it is felt that the above limitations will be sufficient to address data modeling issues and to illustrate the benefits for building maintenance and operation. Purposefully omitted are the interfaces to the model of specific application systems since such interfaces are expensive. They also tend to focus effort and attention on the application capability rather than on the data base issues. Characteristics of the Validation Prototype The validation prototype should be focused on facility management issues as developed by the task analysis working group. A high-level data model should be established containing a view of the important characteristics of the facility covering all phases of its life cycle. One section of the high-level model should be decomposed into a more detailed model of those data involved in the facility management area. Two key characteristics should be visible in this: (1) the thread of the data model between the high-level model and the detailed model, and (2) the interrelations among the entities within the detailed model. At the detailed level, the data model should be established that will support selected realistic user queries representative of facility management functions, the scenarios established, the data models used and the data base management approach implemented. It should be designed to address some of the key data modeling questions identified in the next section. The scenarios tested should be sufficiently illustrative to allow a facility management executive to understand the development risks and the associated benefits of an integrated data management system. It is anticipated that through a validation proto- type, a reasonable subset could be implemented with a relational data management system operating on a personal computer. Scale of Effort in Data Modeling Task Future work on the data model should be aimed at extending the model to cover the needs of the building owners. Three criteria must ensure that this objective is met. First, the data model must be complete, containing information the building owner needs. Second, the data base design must ensure responsiveness, and the time required to retrieve information from the data base must meet the owners' needs. Finally, the data model must be adaptable to the changing information needs of the building owner.
37 Tasks As Figure 3-4 illustrates, the existing data model for the wooden truss used in the prototype demonstration must be generalized, and the generalized model must be expanded to accommodate other tasks. Figure 3-1 identifies the steps that must be followed to extend the general- ized data model to include the additional tasks highlighted by the task analysis working group. Resources The following considerations are important in estimating the resources required to revise the data model: ⢠The effort will require an interdisciplinary team consisting at least of a functional expert and an analyst. The functional expert must identify the functional data requirements such as data required in making maintenance or repair decisions. The analyst's knowledge of data modeling is instrumental in efficiently representing the data relationships in the data base. GENERALIZED DATA MODEL TRUSS DATA MODEL FIGURE 3-4 Generalized data model.
38 ⢠Work done by the demonstration prototype project team provides an excellent starting point for revising the models since many important facility management concepts are already developed. The interdisciplinary teams are already high on the learning curve and can be expected to increase their capability as they expand the data model. ⢠A rule of thumb for the time required to test the validity of a data model is shown in Table 3-1. TABLE 3-1 Rules of Thumb for Testing Data Model Validity Time Units Step 1 1. Task Analysis 4 2. Information Flow Analysis 4 3a. Semantic Model (using data modeling tools) 6 3b. Semantic Model (not using data modeling tools) 4 4. Validity Prototyping Table 3-1 shows that if task analysis takes 1 week, then infor- mation flow analysis will take 4 weeks. The time to develop the semantic model will vary from 4 to 6 weeks depending on whether or not computerized modeling tools are used to ensure integrity in the model. Validity prototyping will ensure that questions concerning data model completeness, responsiveness, and adaptability are successfully answered. FINDINGS AND RECOMMENDATIONS The data modeling group concluded that the data modeling activity should continue, with or without a working prototype in an actual project setting. It recommended that a validation prototype of the IDB be developed, and that the validation prototype be distributed initially to workshop participants and to the client organizations they represent for analysis and evaluation. Finally, the group recommended that the prototype IDB, if developed further, take into account advances in data base technology developed in other areas so that the IDB prototype is acknowledged to contain state-of-the-art character- istics and refinements which will enhance its acceptability and appeal to the building community.
