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 2

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

WEBINAR: On-Demand

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

Type Inheritance in the ORDBMS
Hierarchy within structured complex data offers an additional property, type inheritance. That is, a structured type can have subtypes that reuse all of its attributes and contain additional attributes specific to the subtype. Consider the data in Table 2:

Table 2: Example Data Types

These data types make up the hierarchy illustrated here:



Employee(Name,Salary) / \ Programmer(Language,Project) Representative(Region)

SQL Representation
The following Oracle SQL snippet creates this database:

CREATE TYPE Employee AS OBJECT ( Name VARCHAR2(20), Salary NUMBER(6,2) ) NOT FINAL; CREATE TYPE Programmer UNDER Employee ( Language VARCHAR2(12), Project VARCHAR2(30) ); CREATE TYPE Representative UNDER Employee ( Region VARCHAR2(30) ); CREATE TABLE employees OF Employee; CREATE TABLE programmers OF Programmer; CREATE TABLE representatives OF Representative; INSERT INTO employees VALUES (Employee('Sylvia Karsen', 30000.00)); INSERT INTO programmers VALUES (Programmer('William Helprin', 40000.00, 'C++', 'Seestorm')); INSERT INTO representatives VALUES (Representative('Akiko Yokomoto', 50000.00, 'Asia'));

The "Programmer" and "Representative" subtypes inherit all their attributes from the "Employee" supertype. A request for "employees" objects of the "Employee" type is also therefore a request for objects of its subtypes, namely "programmers" and "representatives". For example, the result of the following SQL statement:

SELECT e.Name FROM employees e;

Would be:

Name -------------------- Sylvia Karsen William Helprin Akiko Yokomoto

Zigzag Representation
The same data hierarchy can be expressed in Zigzag. A separate type definition is not needed:

$readTable() < Employee; Name ; Salary # ; Sylvia Karsen; 30000.00 >; $readTable() < Employee:Programmer; Name ; Salary ; Language; Project # ; William Helprin; 40000.00; C++ ; Seestorm >; $readTable() < Employee:Representative; Name ; Salary ; Region # ; Akiko Yokomoto; 50000.00; Asia >;

A Zigzag request for objects of the "Employee" type is also a request for objects of the "Programmer" and "Representative" types. To get the same result as the previous SQL statement, you would make the following request:

= Name:(Employee:);

With Zigzag, a type is really an object that determines a class (in the sense of multitude) of other objects. In other words, types in Zigzag are also data. Moreover, a type inheritance means not only an inheritance of attribute names but also an inheritance of attribute values. For example, assume all programmers are located in one "E" department. SQL3 demands that the "E" value be inserted in all the rows of the "programmers" table. With Zigzag, you can set up the "E" only for the "Programmer" data object:

$readTable() < Employee ; Department Programmer; E >;

To test an inheritance of "E" value, you'd enter the following Zigzag request, which translates to "the names of employees of E department":

= Name:(Employee:(Department:E));

The result will be:

Name:William Helprin



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