Object Databases in Practice

Description

• Copyright 1998
• Dimensions: 6" x 9"
• Pages: 336
• Edition: 1st

• Book
• ISBN-10: 0-13-899725-X
• ISBN-13: 978-0-13-899725-0

Myths about object-oriented databases are rampant. This book debunks them, so database administrators and managers can make informed decisions about the technology.KEY TOPICS:This book presents comprehensive coverage of the "pros and cons" of object-oriented databases, helping managers and administrators decide whether to implement this powerful technology. Through 18 case studies written by expert practitioners, learn how to identify the right applications for OODBMS systems, and understand the hardware requirements and technical tradeoffs involved. The book also includes many never-before-published tips, tricks and techniques for successfully designing and implementing OODBMS in your organization.MARKET:All database practitioners considering object-oriented database management systems.



Sample Content

Table of Contents

I. SYSTEMS ARCHITECTURE.

Introduction.
1. Object-Oriented Data Integration: Running Several Generations of Database Technology in Parallel.

Abstract. Introduction. Integration Frame. Programmer's View. Layered Model. Object Layer. Tuple Interface. Some Performance Considerations. Further Reading. Product Categories. Remote Database Access Products. Objectified Relational Databases. Federated Databases. Object-Oriented Databases with Relational Gateways. Object-Oriented Access Layers. Object-Relational Databases. Case Study: Persistent Objects in a Large Bank. Situation, Requirements and Software Environment. Why Products Failed in 1995. Our Architecture. Experiences and Summary. References.

2. An Access Layer for Object Databases: Experience Report.

Abstract. A Database Access Layer for ODBMS? The Architecture. Database. Transactions. Error Management. Interface to the Application Kernel. Filters and Iterators. Referencing Transient Objects. Software Production Environment. Experiences and Summary. References.

3. A Use of the EndGame Design Strategy.

Abstract. Introduction. Teaching Our Newcomers a Design Style. Design a Persistent Account Class. The Simple Problem. The Harder Problem. The EndGame Design Technique ("squeegee"). Application of the EndGame Strategy. Move 0: Problem Setup—Identify the Possible Area of Containment. Move 1: Secure the End-Client's Interface. Move 2: Secure the Workstation Object's Internal Design. Move 3: Secure the Distribution Service. Move 4: Secure the Server's Internal Design. Results of Applying the EndGame Technique. How Would One Decide It Is Time to Try EndGame? Comparison of EndGame with Other Design Strategies. Summary. References.

4. Building a Push-Based Information System Using an Active Database.

Abstract. Introduction. Related Work. Design Rationale. Predicate Maintained Collections. Using Predicate Maintained Collections. An Example. Experiences and Summary. Problems. Future Work. References.

II. APPLICATIONS AND DESIGN.

Introduction.
5. Flight-Simulator Database: Object-Oriented Design and Implementation.

Abstract. Introduction: Why Object-Oriented Flight Simulator Technology? Computing Infrastructure. Complex Objects: Airplane Model. Type Constructors: Airport Model. Polymorphism and Covariance. Control System Modeling. Behavioral Modeling: Aerodynamics. Queries. Persistence and Dynamic Binding. Constraints and Triggers. Analysis. Experiences and Summary. References.

6. An Object-Oriented Image Database For Biomedical Research.

Abstract. Problems to be Solved. Image Boss System Overview. Software and Hardware. Various Applications and Tools Implemented. Image Boss Design. Data Abstraction. Class Hierarchy. Future Design Plans. Justification For Selecting OODB. Problems Encountered. Integration of Other Tools. Archiving. Filename Translation. Locking. Queries. Server Crashes. Primary Applications of Image Database. Conclusions. References.

7. The OSEF (Object-Oriented Software Engineering Flow) Framework.

Abstract. OSEF Architecture. General Criteria. Software Development Method. Bought Components. CASE Tool. Database Management System. Source Code Administration Tool. Debugging and Tuning Tools. GUI Builder. Built Components. Framework Class Library. Rational Rose Metaschema Model. Perl Filters and Preprocessors. OSEF Runtime Kernel and Application Control Interface. The Development Cycle. Step A: Modeling. Step B: Implementation. Rational Rose/C++. Diagrams. Exportation/Importation of Items. Code Generation Property Sets. Preserved Code Regions. Tool Evaluation. Release History. Objectivity/DB. Data Definition Language. Storage Classes. References and Handles. Iterators. Associations. Variable-Size Arrays. Physical Clustering of Objects. Indexes. Transactions and Locking. Objectivity/DB Classes in the OSEF Rose Metaschema Model. Database Architecture of OSEF Applications. Performances and Tuning. Evaluation. Release History. Database Browsing and Inspection. Unused Features. Experiences and Summary.

8. Using Objectivity/DB in an Application for Configuration Management.

Abstract. Configuration Managers and Object-Oriented Databases. Requirements of a Configuration Manager. Database Requirements. Using Objectivity/DB to Get an Implement a Configuration Manager. Organization of a Federated Database and Related Limits. The Proposed CM Model. Main Design. The CM Schema. Modeling Information Inside Associations. Final Considerations about Objectivity/DB. Automatic Association Generation in Versioning. Propagation Property of Associations. Evaluation of the CM model. Identification of the Configuration Elements. Change of Configurations. Status Accounting. Granularity. Support in Views. Conclusions. References.

9. Using an OODB for an MIS Application.

Abstract. pc-plus and its Products. A Directory Assistance Call Scenario. The MIS Application. Using VERSANT for MIS. MIS Architecture. Why VERSANT? The OODB's Impact on the Architecture. Software Development Using the OODB. Experiences and Summary.

10. Building a Multi-Petabyte Database—the RD45 Project at CERN.

Abstract. Introduction. The RD45 Project. Object Databases and Standards. Choosing an ODBMS. The ODBMS Market. HEP Event Data. Data Production and Analysis. Early Prototyping. Production Use of an ODBMS for HEP Event Data. The Interface to Mass Storage Systems. Performance and Scalability Measurements. Possible Storage Hierarchy. Use of Very Large Memories. Experiences and Summary.

11. An Astronomer's View of Object-Oriented Databases.

Abstract. Introduction. The Sloan Digital Sky Survey. The SDSS Archives. The Data Products. Typical Queries. Archive Architecture. Platforms, Tools, Libraries. Geometric Concepts. Experiences and Summary. References.

III. OBJECT DATABASE SELECTION AND MIGRATION.

Introduction.
12. On Acquiring OODBMS Technology: An Industry Perspective and a Case Study Comparison of Objectivity/DB and VERSANT.

Abstract. Introduction. Industry Perspective. The Application. ODMG Standard. VERSANT. Design. Query Capability. Objectivity/DB. Design. Query Capability. Comparison. Summary. References.

13. Modeling Battlefield Sensor Environments: An Object Database Management System Case Study.

Abstract. Introduction. Data Model. User Interface. Database Management System. Conclusions. References.

14. Transaction Processing in the Capital Markets.

Abstract. Introduction. Technology Product Set. Relational or Object Database? Relational Databases. Object Databases. Object-Relational Database Management Systems. The Selection for Aurora. ODBMS Selection. Architectural Overview. Language Binding. Building an Object Database Adapter. Approaches to Evaluating an ODBMS. Experiences with Three ODBMSs. GemStone. ObjectStore for Smalltalk. Objectivity/Smalltalk. Experiences and Summary. References. 15 Migration Process and Consideration for the Object-Oriented Vector Product Format to ObjectStore Database Management System.

Abstract. Introduction. ODBMS Integration. Why Use an ODBMS? ODBMS Concepts. ObjectStore. OVPF Design. Introducing Object-Oriented Class Diagrams and Terms. Metadata Classes and Instances. Database Implementation. Persistent Object Webs in OVPF. ObjectStore. Experiences and Summary. References.

IV. PERFORMANCE.

Introduction.
16. Performance Tuning Considerations and Required Tools for an OODB Application.

Abstract. Description of the Application. Performance Criteria. Application System Tuning. Application Tuning Factors. Application/OODB Tuning Factors. OODB Tuning Factors. Application/OODB Monitoring. Experiences and Summary. References.

17. Performance Evaluation and Optimization for a Financial OODB Application.

Abstract. Introduction. Database Access Types. General Directions. Where to Optimize. What to Look For. Levels of Collecting Statistical Data. Transaction Level. Use Case Level. Performance Analysis Tools. UBS Transaction Monitor and Perl Scripts. ObjectStore Performance Expert (OPE). Optimization Areas. Use Object References, Not Foreign Keys. Select Appropriate Transaction Boundaries. Reuse Instances to Avoid Frequent Object Creation and Deletion. Indexes for Associative Accesses. Extent Queries. Reduce Data Transfer for the GUI. Object Clustering. Experiences and Summary. References.

18. A Subjective View of Objectivity/DB.

Abstract. Federation-Wide Indexing in Objectivity. Background. Approaches Considered. Skip List Algorithm. Making It Generic. Benefits. Costs. Encapsulation of a Database Product to Achieve Vendor and Application Independence. Application Independence. Vendor Independence. Why Choose ODMG as the Model? Costs. Creating a Model to Fit the Underlying Database Architecture. Choosing a Database—Academic Comparison Versus Real-Life Usage. Evaluating a Product. Understanding Your Own Requirements. Experiences and Summary.

Index.

Preface

Introduction

Today, the rate of technological change is rapidly accelerating. Organizations are faced with increasingly difficult decisions about their choices for hardware and Software platforms. Furthermore, increasing deregulation in many countries has forced companies into more aggressive deadlines and timescales to compete and survive. At present, object oriented technology is viewed as being able to deliver more reliable and better quality software, because it enables the building of more modular software by using well-defined interfaces and hiding implementation details. This can be seen in Table P-1, which shows the results of a survey of visitors to Object World UK in 1995.


According to Leach Lea95, the top reason shown in Table P-1 was also number one in 1993 and 1994.


The total worldwide sales of object-oriented development tools by US companies in 1995 were valued at US $1.3 Billion OOS96. A breakdown of the figures shows that object-oriented languages were the largest (US $440 Million), followed by application development environments (US $380 Million) and then object- oriented databases (US $218 Million).


Object-oriented languages are quite mature; Simula (the precursor to languages such as C++) has been in existence since the late 1960s. Other languages, such as Smalltalk, have also been used for several decades. On the analysis and design side, efforts are well underway through the Object Management Group (OMG) to develop a standard modeling language to communicate object-oriented designs. The need for a standard modeling language is analogous to Electrical Engineering's need for a standard notation to communicate electrical circuit designs. A standard notation will be understood by engineers wherever they were in the world.


Object databases, however, are still relatively rarely used in production LC96. The reason for this has been that a database is often at the core of many business processes within a company. Changing it can be difficult and expensive, as there may be many application dependencies. In contrast, applications can often be re- written in another language without affecting existing applications. An organization can also switch modeling languages and notions without affecting existing systems or application designs.


The Growth of Object Database Usage

Most of the major commercial object database products were developed towards the end of the 1980s and early 1990s. Many of them were built around object-oriented programming languages and had as their primary objective providing persistence for programming language objects. The computer-aided design vendors were early adopters of this technology. Previously, their approach was typically to store design objects in a relational database or to use some proprietary or flat file system. This approach often resulted in unsatisfactory performance. To retrieve design objects, for example, many database objects may have to be read and reassembled together in memory. For storage, the design objects would need to be flattened or decomposed to be manageable in conventional record or tuple structures. Some examples to illustrate these problems have been described by Loomis Loo95. Over the years, object database technology has become increasingly popular within other industry sectors as well. Evidence of this shift towards non-engineering applications has been reported in Lea95 and shown in Table P-2.


Additional evidence showing the shift to increasing mainstream commercial usage of object databases has been reported by Barry Bar97, based on a study of twenty-four organizations. Results of another survey of 700 Information Technology (IT) professionals in DBW97 showed that nearly 50 percent of respondents indicated that object-oriented databases were a technology area that their companies may use, with the Leisure, Transport, Retail, Healthcare, and Utility industries leading the interest.


The market for this technology has grown steadily over the last decade, although it still accounts for only a few percent of total sales of database products LC96. Part of the reason for this relatively slow market penetration is that the relational vendors have not totally ignored developments in object technology, and have begun to incorporate object features in their products. This is in stark contrast to the way that the hierarchical and network vendors ignored developments in relational technology several decades ago. Relational database usage grew fairly rapidly, because there was no apparent alternative for the capabilities offered by these products. Many companies are hesitant to move to a new data management technology Hod89 partly because there is only a limited experience base to leverage. It is the aim of this book to document examples that demonstrate the use of object database products to solve real-world problems.


This book brings together, for the first time, a large collection of papers that describe first-hand experiences with object database technology. Eighteen papers are presented in four categories:


1.Systems Architecture 2.Applications and Design 3.Object Database Selection and Migration 4.Performance The papers include experiences with five of the major object database products: O2, GemStone, Objectivity/DB, ObjectStore, and VERSANT. The example applications are from a wide-range of domains, such as financial and scientific applications. We expect that this book will appeal to a wide audience, ranging from people who are just starting to look at object database technology to experience object database professionals.


References

Bar97 D. K. Barry: Just the facts, please. Distributed Object Computing. 1 (1): 56- 57, 59, 1997 . DBW97 DBWorld: Report and directory 1997/8. London: Interactive Information Services Ltd., 1997. Hod89 P. Hodges: A relational successor? Datamation. 35 (21): 47-50, 1989. LC96 M. E. S. Loomis and A. B. Chaudhri: The a to z guide to object data management (Tutorial). ACM International Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA'96), San Jose, California, October 1996. Lea95 E. Leach: Object Technology in the UK. Introduction to COBRA. London, UK, September 1995. Loo95 M. E. S. Loomis: Object Databases: The Essentials. Reading, Massachusetts: Addison-Wesley, 1995. OOS96 OOS: The object-oriented software development tools market. Object-Oriented Strategies, May 1996.

Table P-1 Main Reasons for Moving to Object Technology Lea95 Flexibility to change40% Reduced time to market24% Distributed application requirements23% Programmer productivity19% Application complexity18% Ease of use9% Financial savings7% Don't know5% Other17%

Table P-2 Use of Object Databases Commercial applications17% Other applications14% Multimedia applications12% Document management9% Workflow and financial modeling9% Mapping and GIS8% CASE7% Network management5% Scientific applications 5% Manufacturing4% CAD1% Transportation1% No applications will run on ODBMS28%



Updates

Submit Errata

