Crossing Chasms: A Pattern Language for Object-RDBMS Integration

By: K. Brown, B. Whitenack
Published in: PLoPD2
Pages: 227-238
Category: Database

Summary: Crossing Chasms contains architectural patterns, static patterns that define tables and object models, dynamic patterns that resolve run-time problems of object-table mapping, and client-server patterns.

Pattern: Table Design Time

Pages: 229

Design a relational database schema after a first-pass object model done with a behavioral modeling technique. It may be prudent to wait until after an architectural prototype has been built. Doing things in reverse order often leads to a poorly factored OO design with separate function and data objects. See Table Design Time [Brown+96a]

Category: Architectural, Database, Client-Server

• Representing Collections, Representing Inheritance in a Relational Database, Representing Object Relationships [Brown+96a], Representing Objects as Tables

Pattern: Representing Objects as Tables

Pages: 230

To map objects into a relational database, start with a table for each persistent object. Determine the type of each instance variable and create a column in the table.

• If the instance variable contains a collection, use Representing Collections. If it contains any other value, use Foreign Key References. Finally, use Object Identifier to create a column containing the object identifier.
• Representing Objects as Tables [Brown+96a]

Pattern: Representing Object Relationships

Pages: 230-231

To represent object relationships in a relational database, one-to-one mappings become Foreign Key References. One-to-many mappings can use a relationship table. Many-to-many relationships become relationship tables.

• Representing Object Relationships [Brown+96a]

Pattern: Representing Inheritance in a Relational Database

Pages: 232-233

To represent a set of classes in an inheritance hierarchy in a relational database, for each class, create a table that has a column for each attribute in the class and an additional column for the common key shared with all subclass tables. An instance of a concrete subclass is retrieved by performing a JOIN of all tables in a path to the root with the common key as the join parameter.

Pattern: Representing Collections in a Relational Database

Pages: 233-234

To represent Smalltalk collections in a relational database, for each collection, create a relationship table that maps the primary keys of the containing objects to the primary keys of the contained objects.

Pattern: Object Identifier

Pages: 234-235

To preserve an object's identity in a relational database, assign an object identifier to each persistent object, typically a long integer guaranteed to be unique for a class of objects.

• Object Identifier [Brown+96a]
• This pattern is an extension of Identification Scheme

Pattern: Foreign Key References

Pages: 235-236

To represent objects in a relational database that reference other objects that are not base datatypes, assign each object a unique identifier. Add a column for each instance variable that is not a base datatype or a collection. Store the identifier of the referenced object in the column. Declare the column a foreign key. See Foreign Key References [Brown+96a]

Pattern: Foreign Key versus Direct Reference

Pages: 236-238

In the domain object model, when should you use Foreign Key References and when should you use a direct reference with pointers? Use direct references as much as possible. This permits fast over the object structures. Build the object network piece by piece, using Proxy [Gamma+95] objects to minimize storage. Make associations only as complex as necessary.