Types in the Role of Objects
The previous sections in this article demonstrate that the Zigzag language correlates with object SQLat 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:
/ \ | \
/ | / | \
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:
/ \ / \
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 problemstype 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
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.