BIM Interoperability and Relational Databases

Intelligently Linking Drawings and Data

Peter J. Arsenault, FAIA, NCARB, LEED-AP

Architectural practice continues to be increasingly influenced by and dependent on computer technology. Significant advances have been made in hardware and software that allow architects, owners and other design professionals to have ready access to an ever-increasing body of information or data from which to make decisions. Organizing that data so it is in a useful and coordinated form is the ongoing focus of many professionals. Those that take advantage of linking that data together using some fundamental principles discover that they can not only work from a base that is quite manageable, they can also save significantly on time and costs associated with some important work functions such as specification writing and cost estimating. In addition, connecting dissimilar applications is now possible, providing even greater opportunities for improved project coordination and greater efficiency.

Overview of Data Management

Most people who use computers are already quite familiar with databases that stand alone as separate files. A report or specification section created in word processing, a table in a spreadsheet, and CADD drawings are all examples of such stand-alone files. This type of electronic file is also sometimes called a "flat file" and is not conceptually unlike the common flat file drawers that designers have historically used to store drawings. Each flat file is saved and stored separately. Perhaps they are stored with related files in a common folder, but each is distinct from the other with no particular relationship of the information contained in any of them, except as gleaned and perceived by the viewer or occasionally as copied from one to the other.

By comparison, data tables that are linked together electronically create a multi-dimensional storage and retrieval system that is much more powerful than flat files. The common term for this type of electronic file is a "relational database." Simply defined, a relational database is a method of structuring data as collections of tables that are logically associated to each other by shared attributes so that the data can be reorganized, accessed and reported in a number of different ways without having to reconstruct or re-enter the data. The key advantage is the use of organized tables that have basic data entered once. The information in those tables is then connected or linked to other tables by software that allows that data to be used in different useful ways. The "relational" part of the name comes into play because of the way each table is connected, or related to the other tables. A typical relational database has anywhere from 10 to more than 1,000 tables. Each table contains a column or columns that other tables can key on to connect to the information in that table. The specific software type that keeps track of all of the data in all of the columns in all of the tables is called a relational database management system (RDBMS). Essentially, it is software that controls the storage, retrieval, deletion, security and integrity of data within a relational database.

To help illustrate the nature of using a relational database, let's look at a simple example based solely on business data. Architecture firm "A" records all information related to signed contracts as data in a computer flat file with a single table called contracts. In this case, client data must be separately input for each project or contract listed in the table. Since most firms have repeat clients, this separate input duplicates efforts by requiring re-entry and checking of current information while increasing the possibility of errors. By contrast, firm "B" records all contract data in a relational database with two tables called clients and contracts. Records in the contracts table need contain only a reference number to a client, which is fully described only once in the clients table. The RDBMS can then link each contract to the appropriate client for invoicing and other records. In this way, the client information can be updated in one place whenever needed and all affected contracts have the latest information.

Management of drawings, specifications and cost estimates can be greatly enhanced using relational databases. Image courtesy of Building Systems Design, Inc.

 

Information in a relational database adds true multi-dimensional depth while maintaining the presentation advantages of word processing and the analytical powers of spreadsheets. In relational databases anyone can quickly compare information because of the arrangement of data in columns within the tables. The relational database model goes on to take advantage of this uniformity by building completely new tables out of selected information from existing tables. In other words, it uses the relationship of similar data to increase the speed and versatility of the database.

So, how does all of this data management relate to the design process? Well, it relates in more ways than most people may realize. Modern CADD and so-called Building Information Modeling (BIM) programs employ RDBMS for optimal storage and retrieval of data related to design elements. Every element in a BIM model comes with editable attributes that are stored as data in a table. The relationship and linkages between the data in different elements of a BIM assembly are managed by RDBMS. Similarly, specifications can be created using RDBMS to allow intelligent text linking and sophisticated updating either as a stand-alone specification writing process or by linking to related information in other programs. Cost estimating can also benefit by linking products and assemblies with associated equipment and installation costs in a RDBMS to achieve greater efficiency and speed. Although each of these processes separately can be improved by the use of relational databases, a major leap in productivity and improved coordination can be achieved by using software programs and databases that are easily able to share information with each other. Before looking in detail at database management between dissimilar applications, let's look at the specifics of how relational databases can relate to preparing specifications.

Small to Mid-Size Firm Case Study: Bledsoe Architects Bledsoe Architects, located in Shreveport, Louisiana, is a partnership of Benjamin Bledsoe, AIA and Richard Bryan Yeates, AIA, MBA. The firm's experience includes a wide range of architectural design and other detailed client-specific services. They provide services such as strategic and master planning, site planning, project scheduling, new building design, and existing building renovation and restoration. Their projects include healthcare and educational facilities, religious buildings, and restaurants. They understand that different types of projects demand different levels of need and attention. The Need: Bledsoe Architects understands how important it is to meet client requirements. However, in 2004 they realized they had an internal need that was not being met. The commercially available, flat file based, word processing specification program they were using, was not working for them. Formatting and editing were cumbersome. Checking reference standards took a long time. The whole process of creating specifications just took too long. They wanted to find something that would better meet their needs. What they found was relational database specification writing. The Solution: Once he saw how easy it was to edit and format within the relational database system, Ben Bledsoe, AIA, Principal with Bledsoe Architects, was sold on the idea. He says, "What do I like best about the system? It is easy to use–and to re-use. By using the relational database office master, I am able to edit project specifications much faster. I especially like having all choices intact–in case changes are required during project development." Bledsoe estimates his firm is creating specifications in half the time it took with their previous system. He continues, "With the relational database system, it is much easier to make the necessary specification modifications. The global page formatting, headers, footers–everything is much better than the way we used to do it." The Outcome: In addition to the formatting features, Bledsoe also likes how the relational database system helps keep information such as reference standards up to date. And he says that coordination notes have helped to make their documents even better. Not long ago, Bledsoe had two projects he was working on. He recalls, "I recently completed specifications for two separate projects, totaling over $9 million in construction costs. The projects were very similar, yet quite different. I completed them in less than a week. It used to take us weeks to get that much work coordinated and printed." Bledsoe's closing comment, "We would not go back to a flat file system if you paid us."

Creating Specifications with RDBMS

Traditional construction specifications in word processing are organized into individual flat files labeled "sections" that are numbered sequentially. This means that data must be duplicated from section to section, increasing the likelihood of errors. It also means that relationships between sections cannot be readily established and maintained. Specifications for a project are therefore typically organized as a collection of flat files in a folder, with no other actual or virtual relationship. Commercial master guide specifications delivered as flat word processing files require periodic replacement of whole sections, rather than incremental updating of individual text data records, greatly complicating the merging of updates with text that has been edited. Because all text is part of a flat record, instead of individual paragraph records in a relational database, there are no opportunities for linking text intelligently. The flat file structure also means that functions such as data formatting and administrative reports require special "markers" to be embedded in the text, for inefficient sequential processing. In short, traditional specification production using word processing is considered obsolete by many specification writing professionals.

Concept diagram of specifications creation and formatting from a relational database to output. Image courtesy of Building Systems Design, Inc.

 

A typical office master specification may contain as many as 600 standardized "guide" specification sections, so managing and coordinating that many individual flat files can be a real challenge. The advantages of a relational database program over one that is based on word processing are significant. The text of each paragraph is one field in a record that can include other information, such as the text hierarchy and connections to explanatory notes that are stored in other tables. The text records can also include links to any other text record in the database, allowing related information to be activated, highlighted or suppressed. Preparing specifications in a relational database system also has the distinct advantage of organizing all the specification data into a single output file, allowing close coordination of the many sections and the individual paragraphs within those sections. In addition, the single project file can be formatted for page and text appearance in one location and can be expanded or collapsed to provide outline, short form and full construction specs without the need to start over at each phase of a project.

Specifications preparation using a relational database. Data in a table is shown with options on the computer screen and generates a consistent printed result for a given project. Image courtesy of Building Systems Design, Inc.

 

There are other benefits of creating specifications using a relational database management system:

• Intelligent text linkage within and between sections is possible, multiplying productivity and improving coordination. Related sections can be highlighted or selected by choices made within a particular section, while related text within a section can be activated, highlighted or excluded.
• Modification of key terms, units of measure, publication dates, etc. can be made globally across the entire project.
• It's possible to edit a master guide spec by selecting what is to be printed, rather than by deleting what isn't needed, so the master text is always available for future projects, regardless of customization. Choosing what to include in a specific project instead of deleting unneeded text preserves the master for future use. Text added by the user can also be preserved by copying to a master project.
• Related information, such as context-sensitive master notes and project notes, can appear in a separate window, avoiding confusion with the specification text. Related information can be exposed or concealed at will, depending on the need, and the windows can typically be resized and moved for convenience.
• Tagging of text in another record field allows automated report generation without the need to open multiple files and search for information sequentially. Hence automatic generation of table of contents, manufacturers listed in the project, submittals log, etc. are all readily possible.
• Page formats for the entire project are established once and carried through all sections automatically for such things as section style & numbering, page layout, fonts, headers and footers, etc.
• It's also possible to keep all project data in a separate file from the master data, so it's impossible to corrupt the master data file. Updates to the master therefore do not interfere with the project data. In addition, obsolete master data need not be deleted or replaced, merely marked, allowing the spec writer to choose whether to update a particular project or not.

Using the RDBMS approach, it's possible for a specification system to produce documentation for all types of projects and for all phases of a project–from programming all the way through construction administration. In practice, many architects, engineers and specification writers report being able to reduce their specification production time, speed up editing tasks, and update specs automatically and painlessly without disruption (see case studies in this article). Further, they are able to improve coordination of the specifications, reduce errors and omissions, and transition seamlessly from schematic design to design development to full construction specs, all using the same database. Success has also been reported in accessing automated data for simplifying the LEED certification application process and connecting to BIM through a full RDBMS interface.

Developing Cost Estimates with RDBMS

Many cost estimators rely on a spreadsheet database for their work. Calculating costs in an electronic spreadsheet is certainly better than using a calculator and a pad of paper, but spreadsheets also have a number of limitations. Unit costs have to be entered manually or copied and pasted in from another source. Material costs used in multiple assemblies must be changed in multiple places–or must be accessed by developing custom formulas. The formulas connecting the cells for costs, quantities, markups, etc., must be carefully constructed and maintained as items are added or deleted. Commercial unit costs delivered in a flat file format must be copied and pasted or carefully entered into the spreadsheet cells–and updating these costs midway through a project can be difficult. Remembering to include all necessary costs and all building products and processes in every assembly required can be tricky or even treacherous. The flat file structure also means that functions such as special data formatting and compressed or expanded reports are difficult or impossible to achieve. In short, traditional cost estimating using electronic spreadsheets can now be regarded as obsolete.

Cost estimates prepared in a relational database system overcome the limitations of spreadsheets and achieve significant advantages in the process. The RDBMS maintains one table for all product data, another table for all assembly data, and installation crew data in yet another table. Each record in the assembly table is linked to multiple product records in the products table and to an appropriate installation crew, with associated efficiency data. Together, the costs associated with the records in each table make up the total installed cost of the assembly. Each product and each crew are linked to multiple assemblies, but because the data for each is entered only once, the system is far more efficient and can be updated much more easily. In summary, the relational database approach offers the following significant benefits:

Cost estimating with a relational database includes a separate table for assemblies, with each assembly linked to multiple products in a separate table; final output can be compressed or expanded for an appropriate level of detail. Image courtesy of Building Systems Design, Inc.

 

• The relationships between the unit costs, crew costs and assembly costs can be easily established and maintained
• Updating numerous assembly costs is a simple matter of replacing individual records in the product and crew tables
• Adding a total installed cost to an estimate is a simple matter of dragging and dropping one record into the project file

In a fully functioning relational database cost estimating program, parametric models can be constructed that automatically update the cost estimate as the building size is changed. Data can be easily compressed or expanded in detail to suit the project phase and purpose of the estimate. Replacing estimate components is a simple matter of drag and drop – and, not to be overlooked – because all the data can readily be tagged hierarchically, it's possible to collapse or expand the output to suit the need. The cost estimate can therefore be printed with varying levels of detail, depending on the project's stage of development and its ultimate use. A relational database application is a different kind of cost estimating tool. It can be readily used by design professionals such as architects, engineers and others for whom cost estimating is important but not a primary job function. With the relational database system established and in use, it is possible to produce budgetary estimates readily in less than 15 minutes and produce detailed cost estimates at any point in project development. This RDBMS approach leads to time and cost savings within a firm for carrying out this critical service of providing reliable cost estimates to clients and building owners. Perhaps of even greater importance, such a cost estimating system can assist the design professional in determining the likely cost of owner-requested changes and can help assure that the project stays within budget.

Interoperability and BIM

Clearly, the design process can be enhanced in multiple ways by using relational databases and RDBMS within a variety of software applications. But how does this relate to BIM? According to the NIBS National BIM Standard (NBIMS) Project Committee, "Building Information Modeling (BIM) is a digital representation of physical and functional characteristics of a facility. A BIM is a shared knowledge resource for information about a facility, forming a reliable basis for decisions during its life-cycle; defined as existing from earliest conception to demolition." A common misperception about a BIM is that all the information about a project must be included in the 3-D model generated by CADD software. However, even a medium-sized building that has every object from 40-foot-long steel columns down to 1/8-in. setting screws identified with attributes and data chews up a lot of computer memory. The graphic data alone can bring such software to its knees for large projects, so adding detailed specification and cost estimating data is probably not a realistic option. The alternative approach is to distribute the data such that separate relational databases exist generated by the separate applications. Hence, CADD or BIM data resides with its software application while specification and cost estimating data reside with their respective applications. It makes much more sense to regard the BIM as a collection of data about a common project that is stored in separate programs but linked by virtue of an RDBMS. In total, this distributed data makes up the full Building Information Model with the RDBMS serving as the key to its effectiveness and usefulness.

With database information coming from multiple sources, the ability to openly and easily share that information in generic formats without the restrictions of proprietary software becomes critical. The term that describes this open sharing is "interoperability" and is commonly used among a number of computer-based activities with strong precedent elsewhere. In fact, the Institute of Electrical and Electronics Engineers (I-triple E) has spent a considerable amount of effort looking at this topic and offers this definition of interoperability: "The ability of two or more systems or components to exchange information and to use the information that has been exchanged." Some will go on to include the capability to transfer information from one software application for use in another without the need for human intervention or interpretation. The ability of different programs to do all of this depends on the nature of the software and the data being managed. If a software program is fundamentally proprietary and "closed" to other applications, then it will not meet the definition of interoperability. However, products that are based on common data standards and open software platforms can interact with and be understood by other open programs. In the CADD world, it is the difference between the proprietary .dwg format compared to the open .dxf format, which allows one CADD software product to use data produced in another CADD program. However, when we are dealing with fundamentally different software programs, such as CADD, specification writing and cost estimating software, the fundamental requirement is that the data being transferred be both relevant and in a standard format that can be understood and used by the receiving application.

A central data repository is not usually practical. A distributed repository uses a standard taxonomy to allow different software programs to share information and work together. Image courtesy of Building Systems Design, Inc.

Achieving interoperability between dissimilar applications using traditional flat files is not impossible, but it is extraordinarily difficult and inefficient. As a practical matter, then, efficient and substantive interoperability during the design process can only be achieved if all the tools being used employ RDBMS. Why are relational databases so keenly relevant to the problem of achieving interoperability between dissimilar applications? There are at least two significant reasons. First, data in traditional, flat files cannot be accessed easily, so connecting the data between dissimilar applications requires programming queries and clumsy sequential operations. The data in separate flat files is not uniformly identified and is generally unrelated, requiring an extraordinary amount of effort and computing power to make the connections, with uncertain results. Secondly, relevant connections require accurate matching of specific data fields–which is one of the key attributes of relational databases. Obviously, accuracy of connecting the data between 3-D CADD, specifications and cost estimates is critical to the usefulness of the data during design. Hence, harnessing the accuracy and specificity of relational databases is not only logical, it is essential for achieving a real Building Information Model.

Large Firm Case Study: Relational Database Approach Helps WHR Architects Save Time and Money The Methodist Outpatient Center has redefined the skyline of the Texas Medical Center and Houston. Image courtesy of Aker Imaging, Houston, Texas WHR Architects is a 32-year-old firm working on projects throughout the U.S. for top-tier public and private medical and educational institutions. It is a full-service architecture, planning and interior design firm focused on projects in health care, education, science and technology. The Need: WHR found that specifications took too much time to develop using their home-grown office master in word processing. As WHR's number and size of projects increased and the demand on a single specification writer reached a tipping point, they began looking for a new solution. WHR had been searching for a process that would shift more of the specification task down into the individual project teams while maintaining consistency and quality control. The specification director could then focus on firm-wide project manual quality control, consistency, product research and specification practice development. The Solution: Relational database specifications offered WHR a tool that would allow project architects–who were not spec writers–to perform preliminary specification section editing of Part 2 Products for each section, recording initial selections and choices of materials and systems being employed in the project. The relational database functionality made it much more efficient for WHR's dedicated spec writer to complete the sections while performing quality control review of the project team's edits. In addition, specification production using word processing was not keeping pace technologically with software being used for project management, accounting, marketing, design and construction drawing production within the office. The change to relational database systems brought specification production technically on par with these other software programs, elevating specifications beyond simple word processing to the level of an intelligent, interactive database. The Outcome: Relational database specifications helped WHR custom tailor an office master to address the issues of the company's primary building type (health care) while maintaining a "memory" of decisions within the office master across projects. Using the database resulted in significant reduction in time spent updating references and resources, thereby allowing more focus on project issues. WHR says that this change has resulted in a time savings of 40% over other specification programs. Productivity advantages include retention of knowledge across projects, and the ability to add or remove information quickly and efficiently. The ease of incorporating new word processor based sections within the system has allowed WHR to develop over 50 new sections to address specific materials and systems employed routinely in their practice. They have also found global page formatting to be a huge timesaver–not to mention the ability to print a complete project in minutes.

 

Beyond these fundamentals, there is another basic data requirement for interoperability. Although it is possible to connect RDBMS software applications directly by using common data fields, a more practical and universal approach is to employ an intermediary system known as a taxonomy or classification system that can readily be "mapped" to data in each application. Essentially, the standardized, central taxonomy "translates" data between applications by assuring a common identification of elements. In other words, we want to make certain that the brick being drawn in the CADD or BIM software is the same brick being specified and the same brick being priced in the cost estimate. Once we have established the identity of these elements, we can use the data from one application to drive operations in the receiving software. For example, once we know the identity of the objects in the CADD or BIM program, we can activate the appropriate product requirements in the specifications program and turn on the appropriate unit costs in the estimating program. We can also use quantities that are automatically generated by the CADD or BIM program to compute installed costs in the cost estimating software.

Small to Mid-Size Firm Case Study: Gillis and Associates Architects Gillis and Associates Architects' goal is to provide complete architectural services resulting in a built environment that satisfies, in specific detail, the client's physical, social, cultural and aesthetic needs. Master Planning: The firm provides full Master Planning services to access optimum facility placement and phases of development. The goal is to maximize clients' land use potential. Space Planning and Programming: Working closely with clients, they develop intelligent solutions for their environment. This often means embedding themselves in the client's surroundings in order to get a full understanding of the workspace. They are very responsive to client feedback, and hope to establish a close relationship with each client. The Need: Drive through the Costa Mesa area and you will see a number of projects designed by Gillis and Associates. They have worked on police stations, vehicle maintenance buildings and recycling centers. Schools and senior centers also bear the mark of Gillis and Associates. When working on municipal projects, accurate and timely budgets are essential to the success of the project. In 2004, Don Gillis, President of Gillis and Associates, was outsourcing his estimating. This left him unable to provide fast turnaround on budgets. It was taking more of his time to manage the outsourcing. He needed a better way to provide budgetary cost estimates. The Solution: "With the relational database system we are now able to produce cost estimates at least 40% faster than we could before," says Gillis. "This allows us to give our clients an immediate level of magnitude for their projects practically overnight." "The way the front-end cost modeling interface prompts us throughout the process has saved time, too. The master unit and assembly cost databases have also allowed us to generate a ‘best guess' for the construction costs – one that we believe, and one that our clients trust," Gillis continues. "Because the relational database allows us to refine and update the project easily as the design develops, we don't spend time pricing things that haven't been added to the project yet." The Outcome: Once set up, the relational database system was easy for Gillis to learn–it only took about one day before he was able to start saving time and money on cost estimating. Although he has only been using the system for a short time, he has already successfully completed 10 projects. The most recent estimate Gillis and Associates worked on was for the Yorba Linda Water District. Gillis says, "By using different cost models for the project, we were able to shortcut to systems selected to meet a very tight budget." The relational database system has been a great addition to Gillis and Associates. They use it for both new projects and remodeling projects. When asked what he thought of the software, Gillis stated, "We know our estimates are done right which lets us sleep at night. Being able to quickly change quantities, make simple material substitutions and add materials and systems based on our current project type has made a huge impact on both our time savings and accuracy."

 

Conclusion

Given the exceptionally useful nature of relational databases in general, it is only reasonable to expect that RDBMS software would be helpful in the design process, improving specifications and cost estimating as well as graphic building design. Accordingly, it is important for successful practitioners to understand the basic concept and uses of relational databases as compared to alternative data structures. Even more critical is an understanding of how different RDBMS programs can be linked for improved project coordination and to achieve successful Building Information Modeling. True interoperability can be achieved efficiently only through the effective use of Relational Database Management Systems, so it behooves the design practitioner to discover how these systems can be used in this burgeoning BIM era to achieve better quality, greater accuracy, increased efficiency and improved productivity.

 

Building Systems Design, Inc. (BSD) has been developing software applications for the A/E/C industry since 1983 and is currently the only company in the U.S. offering specifications, cost estimating and interoperability software for design professionals. All BSD products are based on relational databases.   www.bsdsoftlink.com