Oracle 8i Data Cartridge Developer's Guide
Release 2 (8.1.6)

Part Number A76937-01





Go to previous page Go to beginning of chapter Go to next page

Roadmap to Building a Data Cartridge, 2 of 5

Development Process

The simplest questions are the most profound: Who? What? When? Where? How? You could say that this chapter is concerned with the when and where of how. But before we examine the road-map to building data cartridges, it would be wise to give a moment to viewing the project as a whole.


The very first step in developing a data cartridge is to establish the domain-specific value you intend to provide. Clearly define the new capabilities the cartridge will make available. More specifically: What are the objects that cartridge will expose to users as a means to accessing to these capabilities?


Who are the intended users of this cartridge? Are they other developers -- in which case the extensibility of the cartridge is of crucial importance. Are they end- users -- in which case the cartridge must be highly attuned to the domain in question. Building a cartridge is a non-trivial project that should be founded in a business model that clearly distinguishes who these users are.

Being realistic about the complexity of building a data cartridge, raises the question of who it is that will perform the task. Are all the necessary skills present in the development team? Most essentially, the developers (be they one or many) must be able to bridge the object-relational database management system with the domain.

When and Where

What are the deliverables? How much time is there for development? Is there a software development process? The project is much more likely to succeed if there are clearly defined expectations and milestones. This chapter should aid you in mapping out a realistic development path.


Choose and design objects so that their names and semantics are familiar in the developer's and users' domain. Given the complexity of the project, you should consider using one of the standard object-oriented design methodologies.

In defining a collection of objects, give care to the interface between the SQL side of object methods and the 3GL code that incorporates your value-added technology. Keep this interface as simple as possible by limiting the number of methods that call out to library routines and by allowing the 3GL code to do a block of work independently. Avoid defining hundreds of calls into low-level library entry points.

With this interface defined, you can proceed along parallel paths, as illustrated in Figure 2-1. You can complete the paths sequentially or alternately work among the paths until you complete all three.

Figure 2-1 Cartridge Development Process

The 'leftmost' of these parallel paths packages any existing 3GL code that performs operations relevant to your domain in a DLL, possibly with new entry points on top of old code. The DLL will be called by the SQL component of the object's method code. Where possible, this code should all be tested in a stand-alone fashion using a 3GL test program.

The 'middle' path defines and writes the object's type specification and the PL/SQL components of the object's method code. Some methods may be written entirely in PL/SQL, while others may call into the external library. If your application requires an external library, provide the library definition and the detailed bindings to library entry routines.

The direction you take at the choice point results from the simplicity or complexity of the access methods you need to deploy, which in turn derives from the nature of the data as represented by columns in the table. If you the methods you need to query your data are relatively simple, you can build regular indexes. By contrast, dealing with complex data means you will need to define complex index types as the basis for making use of Oracle's extensible indexing technology. If you are in addition faced with implementing multi-domain queries, you should choose to make use of Oracle's extensible optimizer technology.

It may be that you do not have execute queries on multiple domains. If I/O is the only significant factor affecting performance, you can make use of standard optimizing techniques. If, however, there are other factors in play, you may still need to utilize the extensible optimizer.

Finally, you will want to test the application and create the necessary installation scripts.

Go to previous page Go to beginning of chapter Go to next page
Copyright © 1996-2000, Oracle Corporation.

All Rights Reserved.