Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Enable Logical Object Representation in Your Database : Page 4

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.


advertisement
Types in the Role of Objects
The previous sections in this article demonstrate that the Zigzag language correlates with object SQL—at least in object-oriented data representation. Zigzag is more expressive and helps when working with more structurally flexible data. Nevertheless, SQL with its type schematization allows stricter control of uniform data. The principal difference appears to be that Zigzag can see a type as a data object and a data object as a type for other objects. This enables it to construct data hierarchies, not only type hierarchies, which is semantically more precise, for example:

production(equipment) / \ printed(equipment:printer,periodicity) video(equipment:camera,...) / \ | \ magazine(periodicity:regular,...) book(periodicity:occasional,purpose) / | / | \ fiction(purpose:entertainment) tutorial(purpose:education) ...

The book object inherits not only the fact that its production is characterized by equipment and periodicity but the fact that equipment is printer. Moreover, book is a type for objects (fiction, tutorial, and others), which inherit attribute purpose and attribute periodicity with value occasional. If instances of book (fiction, tutorial, etc.) are researched target objects, SQL3 represents inheritance with the following type hierarchy:



production(id,equipment) / \ printed(periodicity) video(...) / \ / \ magazine(...) book(purpose)

The book objects stored in a "books" table may be represented with the corresponding attributes' order:

books = [ book('fiction', 'printer', 'occasional', 'entertainment'), book('tutorial', 'printer', 'occasional', 'education') ]

As you can see, attribute values are not inherited. So the "printer" and "occasional" are repeated in each object. The next versions of SQL supposedly will fix such problems—type will contain a static attribute with value, like a static field in Java (static methods already exist in Oracle and DB2 SQL). Such a static attribute is useful in a request that selects all the objects of types with a needed value.

To create objects of the "tutorial" and "fiction" types, a SQL3 developer creates new types and new tables. Or better yet, he or she transforms the existing table to the new. Zigzag developers use "tutorial" and "fiction" objects as already existing types. For example, they can add a "physics" object of the "tutorial" type directly in the database with a single statement like :tutorial:physics(...)=.

In the future, SQL has to possess less expressive constructions than Zigzag, but they have to be reasonably simple to consider types in the role of objects. Flexibility based on the consideration of objects as types remains a prerogative of languages like Zigzag.



Sergey Savouchkine is an ORDBMS specialist who works for Technopoles-M, a Russian Java/Z language developer of Web ORDBMS applications based on "Sav" technology. to email Sergey.
Comment and Contribute

 

 

 

 

 


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

 

 

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