he relational database management system (RDBMS) is based on the relational model, which is simply represented through the relations of rows and columns in two-dimensional tables. Meanwhile, the object-oriented DBMS (ODBMS or OODBMS) offers everything needed for object representation. The newer object-relational DBMS (ORDBMS) like Oracle9i
and IBM DB2 results from combining the RDBMS and the ODBMS.
Two object-relational languages that enable the logical representation of objects in a database are SQL3 (or SQL:1999) and Zigzag. SQL3 (which is not yet in final release nor completely supported by all the well known ORDBMSs) is a calculus language, while Zigzag is an algebra object-relational language.
In this article, I discuss the three properties (complex data, type inheritance, and object behavior) that characterize the O(R)DBMS. I also explain how object-oriented Oracle and Informix SQL compares with Zigzag when used with each property.
Complex Data in the ORDBMS
Are you obligated to define schema before filling your database? Historically, the answer was yes for two reasons. First, the definition of database schema essentially helped to control the type of input data. Second, the data type limitation enabled the early DBMSs to organize data with maximal memory and processor efficiency.
Complex data creation in most SQL ORDBMSs is based on preliminary schema definition via the user-defined type (UDT). Table 1 is the clearest representation of complex data in any ORDBMS.
|Table 1: Representation of Complex Data in ORDBMS|
The "name" attribute (or field or column) consists of the "first" and "last" attributes. The value of the "course" attribute is a set of the "Economy" and "Planning" elements. You can define this structure, for example, with Informix SQL, as below:
CREATE ROW TYPE Student (
name ROW (first VARCHAR(12), last VARCHAR(20)),
course SET (VARCHAR(128) NOT NULL)
CREATE TABLE students OF TYPE Student;
INSERT INTO students
INSERT INTO students
SET('Computers in Engineering')
Other SQL ORDBMSs suggest different composite type constructors (e.g., VARRAY or ARRAY instead of the SET, and OBJECT instead of the ROW). Constructors of the simple built-in types, with limitations like CHAR(5), came from SQL2. Zigzag assumes the above table without using the type constructors, as in the following code through the readTable procedure:
student; name:first; name:last; course
st031 ; Jane ; Hunter ; Economy, Planning
st072 ; Richard ; White ; Computers in Engineering
The first row of input data declares attribute names. The "id" name may be missed, and the "student" will denote both a primary key attribute and a table.