Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Enable Logical Object Representation in Your Database

This article discusses the three properties (complex data, type inheritance, and object behavior) that characterize the object-oriented database management system and explains how two object-relational languages (SQL3 and Zigzag) compare when used within each property.


WEBINAR: On-demand Event

Unleash Your DevOps Strategy by Synchronizing Application and Database Changes REGISTER >

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.

Nevertheless, developing database schema is a most laborious process. Often, precise schema description is not necessary or it unreasonably slows project development. Furthermore, both reasons for schema predefinition are no longer valid: control of input data should be executed by supporting an input form (e.g., via JavaScript on the Web-client side). With the hardware advances in modern database systems, the influence of data type limitation on performance is practically insignificant.

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 ( id CHAR(5), name ROW (first VARCHAR(12), last VARCHAR(20)), course SET (VARCHAR(128) NOT NULL) ); CREATE TABLE students OF TYPE Student; INSERT INTO students VALUES ( 'st031', ROW('Jane', 'Hunter'), SET('Economy', 'Planning') ); INSERT INTO students VALUES ( 'st072', ROW('Richard', 'White'), 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:

$readTable() < 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.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date