United States Patent
`Bannon et al.
`[54] SYSTEM AND METHOD FOR DATABASE
`
`[191
`
`MANAGEMENT SUPPORTING
`OBJECf-ORIENTED PROGRAMMING
`
`[75] Inventors: Thomas J. Bannon, Dallas; Stephen J.
`Ford; Vappala J. Joseph, both of
`
`Plano; Edward R. Perez, Dallas;
`Robert W. Peterson; Diana M.
`
`Sparacin, both of Plano; Satish M.
`Tbatte, Richardson; Craig W.
`Thompson, Plano; Chung C. Wang;
`
`Dand L. Wells, both of Dallas, all of
`
`Tex.
`
`[73] Assignee: Texas Instruments Incorporated,
`Dallas, Tex.
`
`[21] Appl. No.: 531,493
`
`[22] Filed:
`
`May 30, 1990
`
`364/DIG. 1; 364/282.1; 364/283.1; 364/283.4
`[58] Field of Search .................. 364/DIG. 1, DIG. 2;
`
`[51] Int. Cl.s ......................... G06F 3/00; G06F 15/40
`[52] u.s. Cl • .................................... 395/600; 395/500;
`395/425, 600, 650, 700, 725, 500
`
`lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll
`
`US005297279A
`[11] Patent Number:
`[45] Date of Patent:
`
`5,297,279
`Mar. 22, 1994
`
`vol. 19, No. 8, Aug. 1989, CHICHESTER GB, pp.
`719-737.
`Peter Lyngbaek, et al. "A Data Modeling Methodology
`for the Design and Implementation of Information Sys­
`tems", lnt'l Workshop on Object-Oriented Databases
`Systems, 1986,p. 6+.
`Kevin Wilkinson, et al. "The IRIS Architecture and
`Implementation", IEEE Trans. on Knowledge and
`Data Engineering, V2N l Mar. 1990, pp. 63+.
`David Maier, et al. "Development of an Object-Ori­
`ented DBMS", Object-Oriented Programming: Sys­
`tems, Languages and Applications (OOPSLA) 1986.
`pp. 472+.
`Timothy Andrews, et al. "Combining Language and
`Database Advances in an Object-Oriented Develop­
`ment Environment", Object-Oriented Programming:
`Systems, Languages and Applications (OOPSLA) 1987.
`pp. 430+.
`
`Won Kim, et al. "Integrating an Object-Oriented Pro­
`
`gramming System with a Database System", Objec­
`t-Oriented Programming: Systems, Languages and Ap­
`plications (OOPSLA) 1988. pp. 142+.
`(List continued on next page.)
`
`[56]
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`V. Kulik
`C. Loomis
`
`Primary Examiner-Paul
`Assistant Examiner-John
`Attorney, Agent, or Firm-Richard A. Stoltz; Richard L.
`4,525, 780 6/1985 Bratt et al . .......................... 395/650
`
`
`4,853,842 8/1989 Thatte et al. ........................ 395/425
`
`4,989,132 1/1991 Mellender et al . .................. 395/425
`
`
`5,075,842 12!1991 Lai ....................................... 395/425
`
`5,075,845 12/1991 Lai et al . ............................. 395/425
`12!1991 Lai et al. ............................. 395/425
`5,075,848
`5,079,695
`1/1992 Dysart et al . ....................... 395/700
`
`OTHER PUBLICATIONS
`
`Stephen Ford, et al., 'Zeitgeist: Database Support for
`Object-Oriented Programming'; Advances in Objec­
`t-Oriented Database Systems, 27 Sep. 1988, Ebemburg,
`Germany, pp. 23-42.
`R. Agrawal, et al., 'ODE (Object Database and Envi­
`ronment): The Language and The Data Model'; SIG­
`MOD RECORD, vol. 18, No. 2, 31 May 1989,
`Portland, Oreg., USA, pp. 36-45.
`A Straw, et al., 'Object Management in a Persistent
`
`Smalltalk System', Software Practice & Experience,
`14
`
`Donaldson; William E. Hiller
`
`ABSTRACf
`
`[57]
`A system and method for database management for
`providing support for long-term storage and retrieval of
`objects created by application programs written at least
`in part in object-oriented programming languages con­
`sists of a plurality of software modules. These modules
`provide data definition language translation, object
`management, object translation, and persistent object
`storage service. Such system implements an object fault
`capability to reduce the number of interactions between
`the application, the database management system, and
`the database.
`
`4 Claims, S Drawing Sheets
`4 PERSISTENT OBJECT REFERENCES
`
`(PTR INSTANCES)
`_1
`
`Page 1 of 24
`
`UNITED SERVICES AUTOMOBILE ASSOCIATION
`Exhibit 1005
`
`

`
`5,297,279
`
`Page 2
`
`OTHER PUBLICATIONS
`
`Won Kim, et al. "Architecture of the ORION Next-­
`Generation Database Sytem", IEEE Trans. on Knowl­
`edge and Data Engineering, V2Nl Mar. 1990. pp.
`109+.
`Michael Stonebraker, "Object Management in POST­
`GRES Using Procedures", Int'l Workshop on Objec­
`t-Oriented Database (OODB) Systems 1986. pp. 66+.
`Michael Stonebraker, et al. "The Implementation of
`POSTGRES", IEEE Trans. on Knowledge and Data
`Engineering, V2N l , Mar. 1990. pp. 125+.
`
`Puknraj Kachhwaha, et al. "An Object-Oriented Data
`
`Model for the Research Laboratory", Int'l Workshop
`on Object-Oriented Database (ODOB) Systems 1986. p.
`218.
`
`Puknraj Kachhwaha, "LCE: An Object-Oriented
`Database Application Development Tool", SIGMOD
`Int'l Conference on Management of Data 1988. p. 207.
`Laura M. Haas, et al. "Starburst Mid-Flight: As the
`Dust Clears", IEEE Trans. on Knowledge and Data
`Engineering, V2Nl Mar. 1990. [IBM's Starburst] pp.
`143+.
`Ted Kaehler, "Virtual Memory on a Narrow Machine
`for an Object-Oriented Language", Object-Oriented
`Programming: Systems, Languages and Applications
`(OOPSLA) 1986. [Xerox PARC's LOOM]pp. 87+.
`Karen E. Smith, et al. "Intermedia: A Case Study of the
`Differences Between Relational and Object-Oriented
`Database Systems", Object-Oriented Programming:
`Systems, Languages and Applications (OOPSLA) 1987.
`[Brown's Intermedia System] pp. 452+.
`
`Page 2 of 24
`
`

`
`U.S. Patent
`
`Mar. 22, 1994
`
`Sheet 1 of 5
`
`5,297,279
`
`INTERADIVE DEVICES
`
`USER INTERFACE MANAGEMENT SYSTEM
`
`A PPLICATION
`SOFTWARE
`
`OPERATING
`SYSTEM
`S OFTWARE
`
`10
`
`/8
`
`16
`FIG I
`
`SECONDARY MEMORY
`STORAGE DEVICES
`
`j
`j
`- --- -------------------
`
`PERSISTENT OBJECT REFERENCES
`(PTR INSTANCES)
`
`22
`14 I APPLICATION SOFTWARE
`� I
`,
`C++ 40
`I
`42 OBJECT MANAGEMENT S YSTEM
`I
`46 �
`481 50;
`I
`I) ,,
`:
`I
`•
`I
`OBJECT OBJECT TRANSLATION
`SYSTEM /
`I
`MAP
`I
`(52
`PERSISTENT OBJECT J 4
`I
`-----------t -----------
`I
`J
`RELATIONAL DATABASE ;-20
`FIG. 2
`24
`
`18
`
`I
`I
`I
`I
`I
`I
`I
`I
`L
`
`44
`
`(ZEITGEIST INSTANCE)
`
`TYPE -
`DESCRIPTIONS
`
`NAME
`DEM ON
`MANAGER TABLE
`
`STORAGE SERVER "
`
`SYSTEM SOFTWARE ..-
`
`SECONDARY MEMORY
`STORAGE DEVICES
`
`Page 3 of 24
`
`

`
`U.S. Patent
`
`Mar. 22, 1994
`
`Sheet 2 of 5
`
`5,297,279
`
`�--�26 ,--------.
`I oo
`r;o
`C LANGUAGE
`PREPROCESSOR LO
`�
`
`0 '
`
`EXPANDED
`DOL CLASS
`
`DOL
`CLASS t-----+-..,..
`DEFINITION I
`. I
`1
`I
`I
`I
`I ,...------------.
`I
`I
`I .----------....,
`r---;:-:-��.--U
`C++
`CLASS
`DEFINITIONS
`AND HEADER
`FILES
`
`38
`
`FIG 3
`
`C++ TYPE
`DESCRIPTION
`DECLARATION
`FILE
`
`40
`
`48
`• OBJECT ID OF TYPE
`II
`II
`•
`A
`DEMON OBJECT --+----'
`• OBJECT 10 OF TYPE
`"B"
`•
`DEMON OBJECT ----if---+'
`• • • •
`• • • •
`
`14
`
`DEMON FUNCTIONS
`
`DEMON FUNCTIONS
`
`I
`
`44 /'
`•
`44
`/ r .
`
`I •
`
`I •
`
`•
`
`'-+---+-
`
`FIG 4
`
`Page 4 of 24
`
`

`
`U.S. Patent
`
`Mar. 22, 1994
`
`Sheet 3 of 5
`
`5,297,279
`
`50 ')
`
`(
`
`• NUMBER OF STORAGE GROUP-
`HAS H TABLE ENTRIES
`STORAGE GROUP-HASH TABLE ENTRIES
`
`r
`
`NUMB ER ,..
`
`FIRST ENTRY
`
`"'
`
`NEXT ENTRY
`
`,,
`J
`
`t • • •
`•
`
`FIG 5
`
`TYPE DESCRIPTION
`
`• • •
`• •
`
`OBJECT POINTER
`
`62;
`60
`
`I
`
`{ 62
`
`.. ..
`
`FROM DOL
`
`40 -
`
`•
`
`l ENCAPSULATION ;
`44J
`
`• STORAGE 56
`58\
`GROUP LJ
`• STORAGE _... • NUMBER OF ENTRIES
`..
`/60
`• ENCAPSULATION
`
`GROUP
`HASH
`TABLE
`•
`
`• • • • •
`• •
`
`L.= DATA
`-V64
`= MEMBERS
`
`---
`
`FIG 6
`
`Page 5 of 24
`
`

`
`OBJECT IN PRIMARY MEMORY
`
`400
`
`--H-IJoTHIS OBJECT PTR
`MEMBER PTR
`INTEGER
`FLOATING POINT
`ARRAY
`C++ POINTER TO ARRAY OR STRUCTURE
`C++ POINTER TO CLASS INSTANCE
`(DEPENDENT PER�STENT OBJECT)
`
`C++ POINTER TO CLASS INSTANCE
`(INDEPENDENT PERSISTENT OBJECT)
`PTR TO CLASS INSTANCE
`
`(INDEPENDENT PERSISTENT OBJECT)
`
`FIG 7o
`
`#I I
`ENCAPSULATION
`ENCAPSULATION # 21
`
`I
`OBJECT #I
`OBJECT =12 I
`OBJECT # 3 I
`ENCAPSULATION # 31
`
`•
`�
`•
`00
`
`� a n> = ""
`
`� � :" N �
`..... \C) \C) ol:oo
`
`00 =-fD fD -
`ol:oo Q ...., (II
`
`(II ...
`N
`\0
`"--l ...
`�
`"--l
`\0
`
`Page 6 of 24
`
`

`
`424426
`42Bjj0'
`432 434
`436
`
`442;
`444 446
`
`OBJECT IN EXTERNAL REPRESENTATION 4 0 2
`' I�THIS OBJECT PTR
`MEMBER PTR
`INTEGER
`FLOATING POINT
`-A-RRAY
`C++ POINTER TO ARRAY OR STRUCTURE
`C++ POINTER TO CLASS INSTANCE
`(DEPENDENT PER�STENT OBJECT)
`C++ POINTER TO CLASS INSTANCE
`(INDEPENDENT PERSISTENT OBJECT)
`PTR TO CLASS INSTANCE
`(INDEPENDENT PERSISTENT OBJECT)
`INDEX= 3
`# I (ARRAY)
`#2 (CLASS INSTANCE)
`#3 (CLASS INSTANCE)
`FIG. 7b
`
`INDEX= I
`INDEX =2
`
`t-----a�
`
`EXTERNAL REFERENCES 4 04
`OBJECT ID#I 448
`OBJECT ID #2 450
`OBJECT ID # 3 45 2
`• •
`•
`•
`
`•
`�
`•
`rLJ.
`
`""d a ('!) a.
`
`� �
`J� "'""'
`� o5:lo
`
`00 t:r' tD
`� 01 0 .... 01
`
`til ...
`�
`\0
`-l ...
`�
`-l
`\0
`
`Page 7 of 24
`
`

`
`1
`
`SYSTEM AND METHOD FOR DATABASE
`MANAGEMENT SUPPORTING
`OBJECI'-ORIENTED PROGRAMMING
`
`5,297,279
`
`2
`database. POSTGRES is a combination of an extended
`relational and object-oriented database. Objects are
`created using relational table descriptions, while func­
`tions to manipulate the objects are created using the
`
`BACKGROUND OF THE INVENTION
`1. Field of the Invention
`This invention relates to database management sys-
`
`S POSTQUEL query language as well as conventional
`languages (C and LISP). In addition, if the application
`
`developer wishes to add indices over user-defmed
`types, they must write and register with POSTGRES
`functions to perform the various comparison operations
`
`terns and more particularly to a system and method
`providing support for long-term storage and retrieval of 10 between two objects of the same user defined type.
`GRES and C!LISP data models, which can be error
`Computer-Aided Design and Manufacturing, Comput- 15 application system, this strategy does nothing to allevi-
`ate the burdensome requirement to use different lan-
`
`objects created by application programs written in ob-
`ject-oriented programming languages.
`2. Description of Related Art
`Many new computer software applications, such as
`
`Since the latter mode of creating functions requires the
`application developers to map between the POST-
`
`prone and distracting from the task of developing the
`
`er-Aided Software Engineering, multimedia and by-
`permedia information systems, and Artificial Intelli-
`gence Expert systems, have data models that are much
`more complex than previous system, both in content
`
`and interobject relationships. Object-oriented languages 20 in the Intermedia OOPSLA '87 conference paper.
`
`guages and modeling paradigms when building applica-
`tions. This problem of mapping between the object-ori-
`ented and relational data models was discussed in-depth
`
`provide the application developer the mechanism to
`create and manipulate the data models inherent in these
`applications. Database systems provide long term stor-
`age of the data created by these applications. However,
`
`Ontos (Ontologie) and Object Store (Object Design)
`are representative of OODBs employing the last type of
`data model, namely the use of an existing programming
`
`existing languages and databases are insufficient to de- 25 language data model (e.g., using the C++ program-
`
`velop these applications because existing object-ori-
`ented languages do not provide direct support for long-
`term storage and sharing of objects, existing commer-
`cia! database systems (hierarchical, network, and rela-
`
`ming language data model for writing software pro-
`grams and interacting with the database). Both systems,
`however, require the use of a proprietary language
`compiler to add additional code (Ontos) or translate
`
`tiona!) do not support the necessary complex object-ori- 30 new and non-standard C++ language constructs (Ob-
`
`ented data models, and existing database systems re-
`quire an application developer to use different Ian-
`guages and modeling paradigms when building applica-
`tions.
`
`ject Store). As with the first two types of OODBs, this
`approach requires application developers to rely on a
`single source of application development tools, which
`also limits widespread acceptance of these OODBs.
`
`There have been various research and commercial 35 In addition to problems inherent with the type of data
`
`efforts aimed at developing OODBs. These OODBs
`vary in type of data model employed, application pro-
`gram interaction, object access method, method of per-
`sistent object store, etc. Examples of these current
`
`models selected, difficulties occur when an application
`program interacts with an OODB. In the Iris OODB,
`application developers defme object types and develop
`functions to manipulate the objects using the propri-
`
`OODBs, and their weaknesses, will now be considered. 40 etary Iris language. Iris provides an interactive interface
`
`Iris (Hewlett Packard) and GemStone (Servia Cor-
`poration) are representative OODBs employing new
`proprietary object-oriented data models, while Vbase
`(Ontologic), Orion (Microelectronics and Computer
`
`where requests can be made to retrieve or manipulate
`Iris objects. The requests are evaluated by performing
`relational queries (since the objects are stored in rela-
`Technology Corporation), and DOME (Dome Soft- 45 sion, not as object values or references. Iris provides an
`tional tables) and the result is returned as an Iris expres-
`embedded object SQL interface, a c language interface
`(which is not object-oriented), and allows the applica-
`etary data model in order to effectively use the OODB. SO languages. These approaches require the application
`tion developer to register foreign functions written in
`existing (possibly non-object-oriented) programming
`Since their data model is new, using it often results in a
`
`ware Corporation) are examples of OODBs incorporat-
`ing proprietary extensions to existing programming
`language data models. In these types of OODBs, appli-
`cation developers are required to learn a new propri-
`
`developer to map the Iris objects into data structures
`loss of productivity as application developers learn the
`accessible by the programming language, reintroducing
`new language. In Orion, instances of user-defmed
`the problems discussed above.
`classes cannot be stored in the database unless they have
`been derived from Orion-defmed classes. In addition, 55 Similarly, the developers of the GemStone OODB
`also defmed a new language, OPAL, which the applica-
`GemStone and Orion do not allow for an instance of
`tion developer uses to defme object types and functions
`their classes to be transient; that is, every object created
`to manipulate the objects. GemStone provides an inter-
`in a GemStone- or Orion-based application will be
`active development environment for developing OPAL
`stored in the database unless it is specifically deleted.
`
`Another problem with developing a new data model is 60 objects and functions. GemStone also provides a mech-
`
`that it requires application developers to rely on a single
`source of application development tools, such as Ian-
`guage compilers, object libraries, and program debug-
`gers, which limits widespread acceptance of these
`OODBs.
`POSTGRES (University of Berkeley) is an example
`of an OODB employing another type of data model,
`that of a proprietary extension to an existing relational
`
`anism for existing programming languages (C and
`Smalltalk) to interact with GemStone. However, unless
`the applications developer uses only the OPAL !an-
`guage, two data models and languages must be used to
`
`65 interact with the database, mapping the OPAL objects
`
`into structures accessible by the programming Ian-
`guage, and thereby resulting in the problems associated
`discussed previously.
`
`Page 8 of 24
`
`

`
`5,297,279
`
`3
`The Vbase OODB requires two separate languages,
`TDL to define object types, and COP (an extension to
`the C programming language) to develop application
`programs. Although application developers do not need
`
`to map objects between the data model and the pro- s
`
`4
`application developer to specify when objects related to
`the original object should be retrieved. For example,
`application developers can access objects in Ontos using
`one of two modes. In the first mode, an object is explic­
`itly retrieved and referenced objects are implicitly re­
`trieved using an object fault capability. In the other
`mode, one or more related objects can be explicitly
`retrieved, but the application must continually check to
`
`see if a referenced object is already in memory, and then
`
`gramming language, they must still use two languages
`during the development of their programs, with the
`attendant problems considered above. A further restric­
`tion of this system includes the failure to provide access
`10 explicitly retrieve it if is not. This requires the applica­
`to the database from other programming languages.
`tion developer to employ two completely different
`Although the Orion OODB developers used an exist­
`models of accessing persistent objects in the same pro­
`ing programming language, Common Lisp, for their
`gram, which can easily cause errors in the program by
`data model, they developed several proprietary exten­
`the inadvertent and natural use of one mode where the
`sions to the language. As with Vbase, there is no need to
`map between the data model and programming Ian- 15
`other mode should have been used.
`The approach taken by Object Store is quite different
`guage with the Orion OODB. However, this approach
`from the above OODBs with regard to object access.
`requires the use of a proprietary language translator.
`Object Store's model is more like a persistent memory
`The developers of POSTGRES, on the other hand,
`(an extension of virtual memory computer operating
`expect most application developers to write programs
`that interact with the database primarily using the 20
`system) than an OODB. Object Design chose to com­
`pletely reimplement the virtual memory management
`POSTGRES query language, POSTQUEL. Naviga­
`functions of the C+ + programming language and the
`tion between objects is possible; however, a query must
`UNIX (TM) operating system. Whenever a persistent
`be issued to perform the navigation instead of accessing
`object is created or retrieved from the database, it is
`the referenced object directly. Application developers
`installed in a portion of primary memory controlled by
`programming language statements, POSTQUEL query
`Object Design. Thus, references to the object are, in
`statements, and/or calls to POSTGRES' internal func­
`essence, monitored by Object Design's software. If the
`object is not currently in primary memory, it will be
`tions. Thus, application developers may have to deal
`with two or more data models to build their application
`retrieved from the database and installed in primary
`systems. Such requirement fails to alleviate the prob- 30
`memory. This style of memory management requires
`that any class or class library requiring persistence must
`lems considered above.
`be written using this memory management scheme, or
`The Ontos approach provides an interface from the
`C++ language to the database. However, the amount
`perform no dynamic memory management thereby
`resulting in one version of the library for persistent
`of interaction between the program and Ontos is much
`higher than is reasonable or necessary due to the re- 35
`usage and one version for transient usage. Although this
`approach improves the object storage and retrieval
`quirement of specialized functions that must be pro­
`performance, it is inherently dependent on the underly­
`vided by the application developer (e.g., object con­
`ing computer operating system and memory architec­
`struction, translation, storage/retrieval, etc.). This bur­
`ture, and thus not portable to other computer systems.
`dens the application developer with more work that
`Therefore, these approaches either limit how an ap-
`plication program can access an object, or require addi­
`tional work in order for the program to access an ob­
`ject.
`Most OODBs (except for Iris and DOME) have de­
`veloped their persistent object storage facility utilizing
`an existing file management system. They had to de­
`translator, which limits widespread acceptance of their
`system.
`velop new implementations of the disk storage struc-
`tures and management, concurrency control, transac­
`Access to an object in an OODB is performed by
`tion management, communication, and storage manage­
`manipulating the object using predefmed functions,
`using an explicit query, or by coding explicit references 50
`ment subsystems. This approach increases the complex­
`ity of the overall database system software.
`in a programming language.
`The Iris and DOME OODBs, on the other hand, use
`In the Iris OODB, application developers call func­
`existing commercial Relational Database Management
`tions to retrieve or change values in the object. A pro­
`gram cannot receive a reference to an object which
`Systems (RDBMS) to store their objects. Although the
`could be passed to other functions. In the GemStone, 55
`Iris OODB uses Hewlett Packard's relational database
`HP-SQL, it does not use the SQL interface to that data-
`Vbase, and Orion OODBs, individual objects can be
`base, restricting access to the objects to the available
`accessed and passed to functions to retrieve or assign
`Iris functions, Iris interactive browser, C language in­
`values.
`terface, and embedded Iris SQL. Although Iris allows
`In the POSTGRES database, application developers
`the application developer to defme how objects are to
`be stored, the use of Hewlett Packard's RDBMS im-
`poses a limit on the size of an object. The DOME
`OODB, which uses Oracle Corporation's Oracle
`RDBMS, and the POSTGRES system, which has its
`65
`own relational storage system, decomposes objects into
`one or more entries in one or more relational tables.
`This approach requires a relational join whenever more
`than one attribute value from an object is retrieved.
`
`object (actually, relational tuples). POSTGRES allows
`a foreign function to access an object, but as stated
`above, it must be mapped from the relational data model
`to the data model of the foreign function's program-
`ming language.
`Although most OODBs allow the application devel­
`oper to explicitly retrieve an object from the database
`(Iris and POSTGRES do not), they do not allow the
`
`can define and implement their own functions including 25
`
`could have been performed by the database system. 40
`
`Object Store also provides an interface from the C++
`language to the database. However, the interface is
`accomplished by redefining the semantics of or adding
`new C++ language constructs, thereby requiring the
`
`use of Object Design's proprietary C++ language 45
`
`perform queries to retrieve or change values in the 60
`
`Page 9 of 24
`
`

`
`5,297,279
`
`POSTGRES, and DOME, do not allow user-defined 35
`
`clustering of objects.
`
`SUMMARY OF THE INVENTION
`
`In view of the above problems associated with the
`
`related art, it is an object of the present invention to 40
`
`provide a database management system and method
`which supports long term storage and retrieval of ob­
`jects created by application programs, and which uses
`existing object-oriented programming languages to
`
`thereby enable such system and method to be ported to 45
`
`5
`6
`Relational join operations are computationally expen­
`time how related objects, whether created dynamically
`sive.
`or statically, should be clustered when stored, to
`In the GemStone and Object Store OODBs, the unit
`thereby provide a capability to adjust the size of storage
`of concurrency control is not an object but a secondary
`objects to enhance the overall system performance.
`memory segment, or page. This approach can improve 5
`Still another object of the present invention is to
`the performance of secondary memory reads and
`provide a database management system and method
`writes, but results in having the storage facility read,
`that reduces the number of interactions with the data­
`write, and lock more data than may be necessary. In
`base management system that an application developer
`addition, this restricts the amount of concurrent access
`must code to access objects stored in the database.
`to objects since the OODB system, and not the applica- 10
`It is a further object of the present invention to pro­
`tion developer, chooses the unit of concurrency con­
`vide a database management system and method that
`trol.
`allows the application developer to specify at applica­
`Most of the OODBs allow related objects to be clus­
`tion execution time prior to saving a persistent object
`tered together in the persistent object storage. Gem­
`whether or not to install in primary memory the persis­
`Stone and Orion only allow clustering controls to be 15
`tent objects referenced from the given persistent object
`specified when the entire database is defmed. Vbase and
`at the same time when the given object is later installed
`Ontos allow runtime specification of clustering controls
`in primary memory, either due to explicit or implicit
`to store one persistent object as close as possible to
`retrieval, to enhance the overall system performance.
`another persistent object. Object Store also allows run­
`A further object of the present invention is to provide
`time specification of clustering controls to store stati- 20
`maximization of concurrent usage of the objects in the
`database by making the unit of locking the individual
`cally allocated objects in a specific database and dynam­
`ically allocated objects in a specific database or as close
`persistent object instead of a page of persistent objects.
`as possible to another persistent object. This requires
`It is still another object of the present invention to
`the application developer to treat similar objects with
`store objects in a persistent object storage server utiliz­
`different models of clustering, which can cause errors in 25
`ing a relational database management system by storing
`the program by the inadvertent use of one mode where
`an external representation of the object and external
`the other mode should have been used. These systems
`references from the object without decomposing the
`indicate that such clustering specifications are purely
`objects into multiple relational tuples, to enhance the
`hints which the system may ignore. These clustering
`overall system performance.
`hints may require rebuilding of the database if they are 30
`yet another object of the present invention is to pro­
`changed, thereby restricting the ability of the applica­
`vide a database management system and method which
`tion developers to tune the database's performance by
`uses a uniform object translation methodology thereby
`altering the physical grouping of objects. Furthermore,
`eliminating the need for application developers to per­
`the systems based on relational storage, such as Iris,
`form this complex computer-and language-dependent
`task.
`In accordance with the above objects of the inven­
`tion, the preferred embodiment of the present invention
`consists of four software modules to provide database
`services to application developers. They are referred to
`as the Data Definition Language (DDL) translator, the
`Object Management System (OMS), the Object Trans­
`lation System (OTS), and the Persistent Object Storage
`Server (POS Server).
`The present invention presents an application inter­
`face for programming languages which does not require
`other computer platforms without requiring any modifi­
`any extensions to the languages, modifications to exist­
`cations to existing language translators or computer
`ing language translators, or development of proprietary
`operating systems and thereby not unduly restrict appli­
`language translators. Furthermore, the present inven­
`cation developers in their choice of computer platform
`tion implements an object fault capability which re­
`50
`or language translator.
`duces the number of interactions that an application
`It is a further object of the present invention to pro­
`must perform with the database management system
`vide a database management system and method pro­
`and database itself. Access of, and navigation between,
`viding a standard object-oriented programming inter­
`objects can be performed using existing language opera­
`face for its database functionality, thereby eliminating
`tions in a transparent manner.
`any requirement for mixing of object-oriented and func- 55
`Furthermore, instead of requiring the application
`tiona!, or other, programming styles to confuse the
`developers to use one data model to interact with the
`application developer when coding a program's inter­
`database and another data model to manipulate the
`face to that of the present invention.
`objects in a programming language, the present inven­
`It is yet another object of the present invention to
`
`tion uses the data model of existing standard object-ori­
`provide a database management system and method for 60
`nally, thereby allowing application programmers to
`in any object-oriented programming language, and
`
`adding persistence to existing language objects orthogo­
`
`ented languages, such as C++ and CLOS, as the data
`model for the database. This alleviates problems associ­
`ated with the art discussed above.
`Although the present invention can be implemented
`
`treat persistent and nonpersistent objects in nearly the
`same manner and eliminating the need to use two or
`more data models when building application systems. 65
`should therefore not be limited in any way to any spe­
`Another object of the present invention is to provide
`cific language, it has been implemented in both c+ +
`and Common Lisp. In the C++ embodiment, applica­
`a database management system and method that allows
`the application developer to specify at object definition
`tion developers interact solely with the DDL module,
`
`Page 10 of 24
`
`

`
`5,297,279
`
`7
`in a batch processing mode, and with the OMS module
`using standard c+ + syntax in their application pro­
`grams. The DOL module accepts object type descrip­
`tions on standard c+ + programming language state­
`
`ments (with a few additional syntactic constructs) and s
`
`environment in which the present invention's applica­
`
`a specific computer architecture and software system
`tions are to be executed. The POS Server uses a stan- IS
`
`8
`representations in a computer architecture-independent
`manner. When an object is being saved, the OTS mod­
`ule uses the information extracted by the DOL transla­
`tor to determine the extent, or boundary, of the object
`and then translates all of the objects within the bound­
`ary to a computer architecture independent representa­
`extracts sufficient information from the descriptions to
`tion. When an object is retrieved from the POS, OTS
`enable the OTS module to translate objects between
`creates the appropriate primary memory representation,
`their primary and secondary memory representations.
`assigns the object's values from the stored representa­
`This process is required because this type description
`information is not available in the c+ + run-time sys- 10
`tion, and allocates OMS data structures for every refer­
`ence contained in the object to other persistent objects.
`tern. To achieve architecture-independent translation,
`The POS Server module provides a stable storage
`the DOL translator also accepts information describing
`facility for the objects made persistent by the applica­
`tion program. Objects are stored in the computer's long
`term, or secondary, memory. The POS Server also
`provides to the OMS module concurrency control
`dard SQL interface to a commercial relational database.
`primitives and atomic transactions (all objects are saved
`In the Common Lisp embodiment, application devel­
`or none are saved). Objects are stored as an untyped
`opers interact solely with the OMS module using stan­
`array of bytes which only OTS understands.
`dard Common Lisp syntax in their application pro­
`grams. The DOL module is not implemented since the 20
`Server in a computer architecture-independent repre­
`OTS module can extract the necessary information
`sentation utilizing information about the computer's
`from the CLOS descriptions during program execution
`computational, or primary, memory architecture. Infor­
`as that information is already available in the Common
`mation on the content and structure of the objects is
`Lisp run-time system. This embodiment uses a raw
`disk-based implementation of the POS Server devel- 25
`extracted from the object defmitions declared in the
`supported languages. This allows applications written
`oped by the co-inventors.
`in any of the supported languages to store objects in the
`The OMS module presents an application interface to
`same POS. Currently the POS Server is implemented in
`perform standard database operations: initializing and
`a modular and portable fashion using an existing com­
`termin