Browse DevX
Sign up for e-mail newsletters from DevX


Enable Logical Object Representation in Your Database : Page 3

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.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Object Behavior in the ORDBMS
To maximize computer capabilities, DBMSs provide developers with some sort of connection between an external programming language and the internal DBMS language (e.g., ODBC). An additional advantage of transforming (R)DBMS to O(R)DBMS is gaining access from the internal DBMS language to the program objects, namely objects of an external or internal object-oriented programming (OOP) language. Such program objects have to be storable and transportable for database processing, therefore they usually are named as persistent objects.

Inside a database, all the relations with a persistent program object are relations with its object identifier (OID). Mapping the external persistent program objects to a database is not a problem (see, for example, JDO tools and others).

You can describe a restricted real object through traditional database elements like records or even fields. It will be a data object (or database object). The complex data elements I previously described are also data objects. What distinguishes a program object? Each program object can be formally defined as an instance received from the type mapping:

Most significant in this definition, which approximates a program object to a real object, is that object type includes not only attributes but also methods mapped into an object behavior. Some ORDBMSs like Oracle and DB2 make it possible to place methods inside of a data type definition. It enables developers to develop a SQL application similar to an OOP language (and ODBMS) application. Method is a function or procedure defined for a certain class of the objects. The invoking of a method can be represented as follows:

object.method(parameters) = function(object,parameters);


object.method(parameters) = procedure(object,parameters);

Object behavior (methods), which is usually denoted by one name, may be distinguished by the type of object itself or the situation (parameters). The OOP languages call this the polymorphism principle, which in short is "one interface, many implementations." Two other OOP principles, inheritance and encapsulation, are related with both behavior and with the state of an object. Since I've discussed inheritance already in the previous section, I will focus on encapsulation at this point.

The principle of encapsulation in the ORDBMS has other shades. As advanced as they are, even Oracle 9i and IBM DB2 v8 do not take an encapsulation degree through PUBLIC, PRIVATE, and PROTECTED like Java or C++ does. Encapsulation in the ORDBMS is reduced to replacing an attribute with a method or, in other words, using virtual attributes (i.e., using the getPrice() method instead of the price attribute). In the following section, I demonstrate the OOP principles through Oracle SQL and Java/Zigzag.

SQL Representation
The SQL example below creates an "equipments" table of an abstract type "Equipment". Really, a row of the "equipments" table may be an object of either the "Platform" or "Engine" subtype. Each subtype defines a unique getPrice() method:

CREATE TYPE Equipment AS OBJECT ( name VARCHAR2(24), NOT INSTANTIABLE MEMBER FUNCTION getPrice() RETURN NUMBER ) NOT INSTANTIABLE NOT FINAL; CREATE TYPE Platform UNDER Equipment ( size NUMBER, OVERRIDING MEMBER FUNCTION getPrice() RETURN NUMBER ); CREATE TYPE BODY Platform AS MEMBER FUNCTION getPrice() IS BEGIN RETURN size * 6 END getPrice; END; CREATE TYPE Engine UNDER Equipment ( power NUMBER, OVERRIDING MEMBER FUNCTION getPrice() RETURN NUMBER ); CREATE TYPE BODY Engine AS MEMBER FUNCTION getPrice() IS BEGIN RETURN 40 + power * 5 END getPrice; END; CREATE TABLE equipments OF Equipment; INSERT INTO equipments VALUES (Platform('Tower X04', 4)); INSERT INTO equipments VALUES (Engine('Ford U14', 14)); SELECT name, getPrice() price FROM equipments;

The result is:

name price ------------------- Tower X04 24 Ford U14 110

Java/Zigzag Representation
The free realization of Zigzag is based on Java, and it complements Java. It's easy to create a persistent Java object in a Zigzag database and get its attributes or call methods via Zigzag. The object types are described in Java via the following classes:

public abstract class Equipment implements java.io.Serializable { public String name; public abstract int getPrice(); }//Equipment public class Platform extends Equipment { public int size; public Platform(String name, int size) { this.name = name; this.size = size; }//Platform public int getPrice() { return size * 6; }//getPrice }//Platform public class Engine extends Equipment { public int power; public Engine(String name, int power) { this.name = name; this.power = power; }//Engine public int getPrice() { return 40 + power * 5; }//getPrice }//Engine

The following Zigzag fragment creates program objects of "Platform" and "Engine" type, maps their content in the database via $mapState, and prints the table with "name" and "price" attributes like the previous SQL example:

equipment:[ @po Platform.(Tower X04, 4), @po Engine.(Ford U14, 14) ]; $mapState(equipment:); $printTable(equipment:, name, price);

In addition, Zigzag has the unique ability to set not only program objects but also their attributes and methods as multitude. That is a method or attribute that can be expressed indefinitely through the request expression:

  • [object expression].[method expression]() — calling the method
  • [object expression].[attribute expression] — getting the attribute from the program object

  • 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