/ E E Mi~:~u:! ~~nebraker Greg Kemnitz Tm 78 October 1991/Vol.34, No,10/COMMUNIOATION8 OF THI[ ACMommercial relational Database Management Systems (DBMSs) are oriented toward efficient support for business data processing applications where large numbers of instances of fixed format records must be stored and accessed. The traditional transaction manage- ment and query facilities for this application area will be termed data management, and are addressed by relational systems. ~ .......... To satisfy the needs of users out- side of business applications, DBMSs must be expanded to offer services in two other dimensions, namely object management and knowledge management. Object management entails efficiently storing and manipulating nontradi- tional data types such as bitmaps, icons, text, and polygons. Object management problems abound in CAD and many other engineering applications. Knowledge management entails the ability to store and enforce a collection of rules that are part of the semantics of an application. Such rules describe integrity con- straints about the application, as well as allowing the derivation of data that is not directly stored in the database. We now indicate a simple exam- ple which requires services in all three dimensions. Consider an ap- plication that stores and manipu- lates text and graphics to facilitate the layout of newspaper copy. Such a system will be naturally integrated with subscription and classified advertisement data. Billing custom- ers for these services will require traditional data management ser- vices. In addition, this application must store nontraditional objects including text, bitmaps (pictures), and icons (the banner across the top of the paper). Hence, object man- agement services are required. Fi- nally, there are many rules that control newspaper layout. For ex- ample, the ad copy for two major department stores can never be on facing pages. Support for such rules is desirable in this application. A second example requiring all three services is indicated in [6]. Hence, we believe that most real- world data management problems that will arise in the 1990s are in- herently three dimensional, and require data, object, and knowl- edge management services. The fundamental goal of POSTGRES [12, 23, 26] is to provide support for such applications. To accomplish this objective, ob- ject and rule management capabili- ties were added to the services found in a traditional data man- ager. In the next two sections we describe the capabilities provided in these two areas. Then, we turn to the novel no-overwrite storage manager that we implemented in POSTGRES, and the notion of time travel that it supports. The section on the POSTGRES implementation continues with some of the philoso- phy that guided the construction of POSTGRES. Next, we discuss the current status of the system and indicate its current performance on a subset of the Wisconsin bench- mark [2] and on an engineering benchmark [4]. The final section of this article provides a collection of conclusions. The POSTGRES DBMS has been under construction since 1986. The initial concepts for the system were presented in [23] and the initial data model appeared in [ 19]. Our storage manager concepts are detailed in [21], and the first rule system that we implemented is discussed in [25]. Our first "demo- ware" was operational in 1987, and we released Version 1 of POSTGRES to a few external users in June 1989. A critique of Version 1 of POSTGRES appears in [26]. Version 2 followed in June 1990, and it included a new rules system documented in [27]. We are now delivering Version 2.1, which is the subject of this article. Further in- formation on this system can be obtained from the reference man- ual, the POSTGRES tutorial [12] and the release notes. POSTGRES is now about 180,000 lines of code in C and has been written by a team consisting of a full-time chief programmer and 3-4 part-time students. It runs on Sun 3, Sun 4, DECstation, and Se- quent Symmetry machines and can be obtained free of charge over the internet or on tape for a modest reproduction fee. 1 The POSTGRES Data Model And 0uery Language Traditional relational DBMSs sup- port a data model consisting of a collection of named relations, each attribute of which has a specific type. In current commercial sys- tems possible types are floating- point numbers, integers, character strings, money, and dates. It is com- monly recognized that this data model is insufficient for future data processing applications. In design- ing a new data model and query language, we were guided by the following three design criteria. • orientation toward database ac- cess from a query language. We expect POSTGRES users to in- teract with databases primarily by using the set-oriented query lan- IFor details on obtaining POSTGRES, please call or write: Claire Mosher, 521 Evans Hall, University of California, Berkeley, CA 94720; (415) 642-4662. • OMMUNI•ATIONS OF THE A•M/October 1991/Vol.34, No.10 7guage, POSTQUEL. Hence, inclu- sion of a query language, an opti- mizer and the corresponding run-time ..system was a primary de- sign goal. It is also possible to interact with a POSTGRES database by utilizing a navigational interface. Such inter- faces were popularized by the CODASYL proposals of the 1970s and are used in some of the recent object-oriented systems. Because POSTGRES gives each record a unique identifier (OID), it is possi- ble to use the identifier for one rec- ord as a data item in a second rec- ord. Using optionally definable indexes on OIDs, it is then possible to navigate from one record to the next by running one query per nav- igation step. In addition, POSTGRES allows a user to define functions (methods) to the DRMS. Such functions can intersperse statements in a pro- gramming language, query lan- guage commands, and direct calls to internal POSTGRES interfaces, such as the get_record routine in the access methods. Such functions are available to users in the query language or they can be