Oracle 8 Seminar (November 1998)

PDM was invited to a one day seminar,presented by Doug Benson (D A Benson & Associates) – to learn all about designingan Oracle 8 database with objects. We offer this digest of an excellent course, and anintroduction to what OO means to Oracle.

When you think of Oracle 8 and objects, you think of Object Extensions and the Cartridge technology. But a careful reading of the course title indicates that this was not a seminar on these topics. The Oracle 8 Object Design seminar focused on the actual process of designing a database with OO techniques. Rather than attempt to say what an object is – or what OO means, Benson offered a functional definition of the different users of the technologies. Currently Oracle provides tools for database designers which focus on the use of SQL.

The new design tools cater for programmers who require a C++ Application Programming Interface (API). Just as relational database designers use Entity-Relational modeling tools such as Oracle’s Designer 2000, the new Object Database Designer route to a C++ API uses the object world’s equivalent, Universal Modeling Language (UML) design tools. We offer the following table to help distinguish between the C++ OO brigade and the SQL coders.

While Oracle 8 is still basically a relational database, it increasingly incorporates functionality that allow the user to model objects that are hard to fit into the conventional object world. As an example, consider well log trace data. The ‘natural’ way of modeling this is as some sort of header relating to the well’s position and other metadata, and some big vectors representing the trace information. It is possible to store each log value in a table of the database as a depth-value pair, but this is inefficient, since extra metadata must be stored with each pair of values. This may not seem too much of an issue, but in the case of a well log tool acquiring multiple measurements per depth point, the concept of tables within tables comes in, and the need for non-relational modeling rears its head naturally.

The provision of a C++ API can, in the simplest case, involve reverse engineering an existing Oracle DB into the Object Database Designer (ODD). This currently produces a proprietary graphical notation, but is ‘moving to’ UML. The UML can then be edited before itself being used to produce C++ code. Those familiar with the POSC Epicentre data model will know that it is designed in Express. The UML language can be thought of as a graphical equivalent of Express. Some limitations of the OO design technology were emphasized in the seminar. It is not intended that the OO technology be implemented in a totally uncompromising manner. There are limits to the amount of imbrication in a design and OO concepts such as inheritance are implemented in a half-hearted sort of a way. Marketing-wise this is a fairly astute approach from Oracle. OO databases have had a checkered past, and the ring fencing of the OO design in ODD would allow Oracle to carry on with a mainstream relational product with even limited interest for the ODD side of things. If it does pick up, the technology could be given more exposure.