erving up complex data that's way beyond your current server's capabilities. What are you going to do?
The long-awaited new version of the Oracle relational database management system (RDBMS), Oracle8, is finally available in an extended beta release, and it delivers strong performance gains for large database configurations as well as a strong object-relational typing system that gives you the ability to handle new kinds of data.
If you need to allow many simultaneous users to log on to a database, or if you need to back up and restore huge databases, or if you want to store and retrieve data that just doesn't fit well into standard relational tables, Oracle8 offers some real solutions.
Before getting into what this new package does, it's important first to point out what it is not -- Oracle8 isn't what we normally refer to as an object-oriented database management system (OODBMS). Those systems offer full data encapsulation, inheritance, full in
tegration with OO programming languages, and all the other defining characteristics of OO software; Oracle8 does not. [
Editor's note:
Several OODBMSes will be examined in the Software Lab Report scheduled to appear in the October BYTE
.]
Instead, Oracle8 is an object-relational system; it adds a layer of data abstraction on top of the standard relational methods of representing data and programming, and it also provides the ability to extend the storage mechanisms to cope with complex data types. The object-relational data abstraction that Oracle8 provides gives you the ability to add new data types to standard SQL (see the sidebar "Roll Your Own Data Types") and to store and retrieve arrays of values and nested tables (e.g., column values that are themselves tables) and methods (i.e., stored subprograms that you associate with the new object types). However, there's no inheritance system for the types you add, nor can you hide the data columns in your object types.
Finally, the obj
ect-relational system provides you with a way to make your complex objects look like relational tables; Oracle calls this the object view. While these features do not give you true OO database-programming capabilities, they nonetheless extend the already-strong Oracle RDBMS into the object world in a tremendously useful way.
The strength of Oracle has always been in its strong server capabilities: security, integrity, concurrency, and high-volume transaction processing. Oracle's high performance, reliability, and wide availability on many different operating platforms have catapulted the product into the forefront of the database market. Oracle8 extends these strengths with additional client/server capabilities and adds the object-relational extensibility that the new application world needs.
Object Lessons
If you've been holding off looking at Oracle8 because you're afraid of the learning curve, it's now time to take the plunge; Oracle8 really isn't all that much different from Oracle7.3
. For a database administrator (DBA) experienced with Oracle7, learning the new features won't take long. If you're currently programming database applications in C++, you will benefit from the new type features, and it likely won't take you long to get used to them or to the new OCIAPI (the Oracle Call Interface, a set of functions that allow a program to send SQL to Oracle8 and get data back). In fact, the beta process has greatly improved the structure and capabilities of the OCIAPI as compared to the earliest versions.
Nonetheless, I'm not about to describe OCI programming as easy, so it's good that there's an alternative programming interface: Pro*C/C++. This precompiler technology gives you somewhat easier access to Oracle8's major enhancements to SQL, including an extensive new system of object types, tables, and views; large object (LOB) and image data types; collections of objects (VARRAYs, or variable-length arrays, of data and nested tables); and table partitions.
Object types let you d
eclare new SQL types, which you can then use to define tables, columns in tables, or attributes of other types. See the sidebar "Roll Your Own Data Types" for some details of object types. In addition to representing complex types, you have the ability to link objects through references (REFs) and store those pointers and dereference them on demand. Object views let you construct objects from old-style relational tables for programming purposes, integrating such tables with the full object-relational programming facilities in Pro*C/C++ and the OCIAPI.
LOBs are special data types in the Oracle RDBMS server engine. Unlike with the old LONG data types, you can declare as many LOB columns as you need in your tables. There are four LOB types: BFILE, BLOB, CLOB, and NCLOB (see the table
"Four Varieties of LOB"
).
In addition to these flavors, there's a built-in image type, implemented as a Network Computer Architecture (NCA) data cartridge, that uses BLOB and BFILE types and a set o
f object types to represent image objects. LOB types provide a much more powerful means of representing complex data than the old LONG and LONGRAW data types did. They also relax the single-BLOB limitation that the use of LONG data imposed.
The disadvantage of these types, as always, is that they are not objects, just raw data. It's up to your program to interpret the results. At least for the image types that the image-data cartridge supports (BMP, CALS, GIF, JPEG, Kodak Photo CD, PCX, PICT, Sun raster, Targa, and TIFF), you get some SQL extensions that let you do more programming, such as changing formats, copying, scaling, and other image-related operations, in the database. These types show what the NCA and Sedona environments can do; unfortunately, these aren't available yet for your own data cartridges. (As this review went to press, there was much confusion over Sedona because of remarks made by Larry Ellison, CEO of Oracle Corp., saying that the product had been placed on hold, and denials of th
is by other sources at Oracle.)
The collection of objects lets you represent either variable-length arrays of data or tables nested within other tables, extending the original relational first-normal-form model, which required a single value of a column for each row. Now each value can be an array of values or even a complete table.
Table partitions add the ability to store tables (and indexes, too) in more than one data segment. This allows you to store a table on different disks or in different locations that are under your control by allocating multiple tablespaces and assigning rows to the different partitions according to their data content, as the figure
"Table Partitioning"
illustrates. You can use table partitioning to replace complicated disk-striping performance optimizations to speed up access or to allow for taking part of a table off-line for maintenance or backup without interfering with the rest of it. This is a major improvement for huge tables, which are incr
easingly becoming a requirement for many large databases.
Another use for partitioning is to simplify and speed parallel processing. In particular, if you're using data manipulation language (DML) operations in parallel, your tables must be partitioned so that each operation is confined to a single partition. (Often, much of this type of processing involves large batch jobs.)
What about Pro*C/C++ programming? This is the alternative to messy programming with OCI, the precompiler that takes an embedded SQL program and turns it into C++ source. I wish I could report that the enhancements that have been made to Pro*C/C++ make programming with objects easy, but they do not. First, you have to use a completely separate utility, the Object Type Translator, to produce header and
typefile
files for your object types. Unfortunately, this produces C++
structs
, not classes, which means that object-oriented C++ programmers won't be happy with the results.
There's more: Pro*C/C++ uses
an object cache to create these
struct
objects in memory, and you must use explicit embedded SQL commands to allocate and deallocate memory rather than the standard C++ free-store facility. The advantage of going through all this is that you can extract object data using SQL. One disadvantage for those used to OODBMS behavior is that you need to use explicit UPDATE statements to move changes from the object cache back to the database. It doesn't happen automatically when you commit your transaction.
On the downside, however, Oracle8's SQL, called SQL*Plus, conforms to the Entry level of the SQL1992 (SQL2) standard. This sounds great -- until you realize that the Entry level is pretty close to the SQL1989 standard and does not include most of the neat features of the 1992 standard, such as the extended FROM clause syntax for inner and outer joins, the orthogonal use of SELECT queries in lots of interesting places, the TIMESTAMP and INTERVAL data types, and the character-set features, which are m
uch cleaner and easier to use than Oracle's National Language Support.
Also, the development tools (Designer/2000, Developer/2000, Pro*C, and JSQL for Java) still lag behind the server technology and don't yet take advantage of the new object features. The graphical tools for the DBA's use, such as Oracle Enterprise Manager (
shown in the screen
), haven't changed much and still are not particularly easy for a DBA to use. However, the DBA now has the ability to administer passwords through this as well as through Oracle8 directly using SQL*Plus, which is a new capability.
Finally, until Oracle releases its Sedona project, you won't be able to add your own data cartridges to the system to construct your own data types. Only the Oracle-built cartridges will be available until Sedona comes out.
The new backup and recovery managers will make life a lot easier for the ever-suffering DBA and system administrator by fully automating the backup process and by providing better inc
remental backups than Oracle7. Because I did not benchmark the product, however, I was unable to verify many of the claims of improved architecture, memory use, performance, and scalability. But the beta version that I used was refreshingly bug-free and performed well on a Pentium-133 NT-Workstation system.
Overall, I was impressed by the engineering in Oracle8, if not entirely happy with the product's design and integration. If you need complex objects and you're willing to write complex C, C++, or COBOL programs to use them, this is a great tool. Otherwise, you might want to wait for upgrades to Oracle's application-development tools that take advantage of Oracle8. But if you're an Oracle7 user and you need the advanced performance features of Oracle8 for very large applications, you should start exploring Oracle8 now to see if it meets your needs.
Where to Find
Oracle8................................Price not yet available
Oracl
e Corp.
Redwood Shores, CA
Phone: 800-672-2531
Phone: 415-506-7000
Internet:
http://www.oracle.com
Enter 1011 on Inquiry Card.
Oracle8: Worth the Wait?
