Object-Relational – An Area With Some Theoretical Promises and Few 47 Practical Achievements

Object-Relational Databases: An Area with Some Theoretical Promises and Few Practical Achievements

Marin Fotache, Al.I. Cuza University of Ia şi, Romania, [email protected] Cătălin Strîmbei, Al.I. Cuza University of Ia şi, Romania, [email protected]

Abstract decisive in dominance, even if today This paper tries to point out some of the promises, SQL is seen by the relational “purists” [2] as a traitor quarrels, achievements, and perspectives of the of “relational laws”. forced marriage between the relational and object- oriented data models, from both theoretical and At the end of 1980s many scholars and professionals implementation perspectives. As practical O-R felt uncomfortably with relational rigidity. Compared achievements, the latest SQL standards with OO, what relational systems lacked (SQL:1999-2008) and Oracle implementation are most were abstract data types, complex integrity discussed constraints and versioning [3]. So the OO data model was seen as a a better alternative to relational model Keywords: Databases, Object-Relational model, because it could store persistent objects – data SQL, Oracle, Java (properties) and code (behaviour). The idea of storing pieces of code within the database was not 1. Introduction related, as expected, only with OO model. The The computing history has recorded many clichés network model (CODASYL) allowed database and misunderstandings. One of them is Object- procedures, written in whatever programming Relational (O-R). The major producers (Oracle, language, to be invoked [4]. For relational databases, IBM) have stated that their DBMSs manage O-R [4] were among the first to propose stored databases. Most of the applications developed in procedures. Actually, their idea was more generous the latest years combines Object Oriented (OO) and even compared to current implementations – to have Relational technologies. So the idea that O-R fields in tables which have as value a collection of model of data rules the database world today is commands in the query language supported by the quite logical. In fact, this is not quite true. DBMS.

At the beginning of the 1990’s the OO wave struck 3. Towards an Object-Oriented Data Model the database world [3][5][6]. Surrounded by an According to Kim [5], OO concepts evolved in three immense interest in OO technologies, relational different disciplines: first in programming languages model sinking seemed to be a matter of time. (Simula-67, Smalltalk, C++), then in artificial Relational database market was assumed to be intelligence (KEE, ART), and then in databases eclipsed by the new OO database products before (semantic data models). The paradigm of OO 2000. But something went wrong, and now programming is the encapsulation, within an object, OODBMSs cover just a tiny niche in the market. of both the data and the programs which operates on data. Data is the state of the object (values of the Today, all the methodologies, tools, and platforms attributes), and code is the behaviour of the object. for application development are (more or less) OO, The behaviour is invoked via messages through the except the databases which remain “a relational interface. island”. The basic problem of “impedance mismatch” remains, and much effort is spent these Despite the accessibility and naturalness of OO, days in mapping the application objects to database defining an OO data model has been a daunting task relational table rows. [3] [5] [6]. As for OODBMS, initially there were two main approaches [3] [5]: extending a relational DBMS with new data types, operators, and access 2. Relational model, purists and traitors methods; and extending an OO programming Almost ten years passed between the publication of language with database functionality (persistence, the E.F. Codd seminal paper [1] which marks the authorization, concurrency). birth of relational data model and first commercial RDBMS. But within few years the market felt the A highly influential paper in establishing OO data expansion of the relational database products. model as academic and research fields is [6]. It claims a “pure” and orthogonal database adoption of There are many advantages which can explain the object oriented model. The basic idea is to tremendous success of the relational databases: transparently handle the objects’ pool and their clear, short and deep theoretical foundations relationships, produced by OO applications, between (predicate logic), better and better DBMSs persistent (database) and transient (in-memory) performance in storing and querying data, very contexts. active and enthusiastic communities of researchers and professionals, etc. SQL popularity was also The most distinctive feature of the object oriented Communications of the IBIMA Volume 9, 2009 ISSN: 1943-7765 48 Marin Fotache and Cătălin Strîmbei database systems consists in the concept of OO and relational models of data. Ullman [7] “orthogonal persistence” [9] defined by three anticipated the “synthesis of object- and value- fundamental principles: oriented systems”. More astonishing, Premerlani et - independency : the application is not depending on al. [3] used the expression OO Relational Database the manipulated data lifetime (no distinction to define a database system which combines a between transient and persistent objects); relational DBMS with an OO programming - data types orthogonality : objects could become language. Their basic idea was to buffer the database persistent no matter what is the type that they are with an OO layer that keeps relevant data in memory. defined on; The OO layer would hide the database from - persistent identity : the mechanisms to identify and applications. supply persistent objects must be orthogonal regarding database system context. Nevertheless, the O-R does not deal with mapping application OO modules of code to a relational These principles resemble to data independency database, but how to store and manage natively ANSI/SPARC principle but generalized and object instances in table tuples. applied over objects instead of relational data. Unfortunately this “object” independency principle The first major theoretical development of O-R data has not surpassed the proposal level. OODBMS model is [13]. Thought as a reaction to [6], the article providers do not cross the boundary of a single OO argues that the next generation (the third one) of programming language by offering cross-languages database systems would be, in fact, extensions of persistence mechanisms. Their mechanisms are relational model, proposing thirteen features to be much like extensions (as a specific API) of existing incorporated, such as: application platform, built around a programming - rich data types - complex objects and abstract data language. The lack of compliance with the types to model complex structures as meaning to principle of data independency and the mathe- overcome the relational model “flatness”; matical “weaknesses” of object oriented models’ - inheritance (including multiple inheritance) - foundation, are the major reasons of OODBMS mechanism to get new from existing ones though blame by relational theorists. derivation (no mater what it is about base or abstract types) taking into consideration the structure as well The authors of [6] define three categories of as object manipulation function inheritance; characteristics to be fulfilled by a DBMS in order - functions, including database procedures and to be declared OODS: methods Mandatory : complex objects, object identity, - unique identifiers (UIDs) should be assigned by the encapsulation, types (classes), inheritance, DBMS only when a user-defined primary key is not overriding combined with late binding, available; extensibility, computational completeness, - rules (triggers, constraints) - active rules to handle persistence, secondary storage management, the events or actions materialized as queries as well concurrency, recovery, and ad hoc query facility; as updates; Optional : multiple inheritance; type checking and - non-procedural, high level access language; inferencing, distribution, design transactions, and - at least two ways to specify collections (by versions; enumeration, and by query language); Open : programming paradigm, representation - updatable views system, type system, and uniformity. - database accessibility from multiple high level programming languages; The major OODMBS producers gathered - SQL support. (www.odmg . org ) and yielded three standards of OO database language: ODMG 1.0 in 1993, As a reaction to first manifesto [6] and the second ODMG 2.0 in 1997 and ODMG 3.0 in 2000. The one [13], Chris Date and started in standards technical problems [10], the insignificant 1995 a series of papers and books which OO share in the database market and the OO circumscribe the so-called The Third Manifesto [2] advances in SQL:1999 leaded to group disbanding [14]. If [6] argued for replacing relational model with in 2001. The market share looks disastrous for an OO one, and [13] tried to conciliate the two OODBMS producers. The main technical models, the third manifesto is a frontal attack not drawbacks for OODBMS market failure have been, only to OO data model (without blaming object according to Leavitt [11], the strength of object- orientation), but also to SQL standards. The basic relational producers, bad performance and poor idea is that objects are orthogonal, and the relational standardization. model can manage both standard (primitive) and user-defined (composite) types, no matter how 4. Object-Relational Strands complex they are. So the relational model “needs no The combination of the two data models, relational extension, no correction, no subsumption, and, above and object-oriented was proposed before coining all, no perversion” [2]. the term object-relational. For example, Cattell and Rogers [12] announced a DBMS which combined As consequence, two strange directives were Communications of the IBIMA Volume 9, 2009 ISSN: 1943-7765 Object-Relational Databases – An Area With Some Theoretical Promises and Few 49 Practical Achievements prescribed [14] to the database developers: distinct components, user-defined types and typed Relational Model Proscription 10: Not SQL and tables . Relational Model Very Strong Suggestions 9: SQL migration . Date and Darwen justify their “war There are three kinds of user-defined types. First, declarations” against SQL by stating that SQL distinct types are based on a single built-in data type (especially SQL:1999) has undermined the (ex. INTEGER, VARCHAR), whose values cannot traditional relational by extending the model in the be directly mixed in operations with that built-in type wrong direction: the object oriented features are or other distinct types; they can be used to define included in a completely isolated manner, defining columns, just like any SQL built-in type [16]. object structures above relational ones and not on Second, structured user-defined types as values , such their basis. The final result: we can store objects in as address type composed by street, number, city, tables. Instead they had reconsidered the concept of county, zip code. As distinct types, structured types domain (already defined in traditional relational as values can be used for defining the type of the theory as a set of values) and they treated it as real columns within tables. Third come structured user- (abstract) data type thus applying it the OO defined types as objects . In a typed table, every row principles like encapsulation and inheritance. The is an instance of a structured user-defined type as result: tables are variables, these variables contains object. The table has one column for each property sets of TUPLES (with their own types), and the (attribute) of the user-defined type the table is value of each TUPLE contains a complex of values defined on, and also a self-referencing column which (attribute values) selected from a scalar type, is the unique object identifier (OID). TUPLE type or RELATION type. As for collection types, SQL is not complete or as Despite the quarrel, there is some degree of rich as other OO languages. The only collection type equivalence between SQL last standards supported by SQL:1999 is ARRAY. In SQL:2003 (SQL:1999-SQL:2008) and [14] model, but the MULTISET was added. It is equally true, that many rigorous manner in which Date and Darwen commercial implementations have their own propose the reformation of the relational model collection types, more or less conformant with system type in conformance with the abstract data standards. types theory make their approach more closed to conceptual model constructs. Also, Date and A major drawback of SQL standards is the lack of Darwen demand a clear distinction between support for declaration of integrity constraints on specification and implementation of types. DBMS types. It is amazing because some papers argued that language (D language) must not have any reference OO model in better than relational in terms of to how a type (scalar or non-scalar) has to be integrity rules which can be implemented. The implemented. This principle can be exploited in an formal definition contains no definition in this interesting way: the implementation of types can be regard. The only way of declaring constraints in SQL provided in a independent manner, so the DBMS is CREATE/ALTER TABLE. might allow to construct the implementation in language like Java or C++, but the types to be The “type” notion seems to be the key of the Date exposed in the databases language (be it SQL or D) and Darwen theoretical foundation and also, the which is one of the O-R criteria proposed by “abstract type” is the cornerstone of the Stonebreaker Stonebreaker to the “new wave” of DBMSs [15]. conception to extend existing relational systems. More specific, in D language [14] there are types Implementing the logical model proposed by the everywhere, scalar and non-scalar (TUPLE and SQL:1999 standard and The Third Manifesto is a RELATION) and these categories of types support “mission impossible” because of inexistence of a the principles of full-packaging (scalar type with no real product (DBMS) to do this task. The problem components, but with possible representations), user is that the commercials DBMSs do not extend the defined components (non-scalar types), inheritance relational model in the same way, but are closer to and substitutability (either scalar or non-scalar), but the SQL standards than [14] model. without identity.

5. Object-Relational Features in SQL In SQL new standards there are several categories of Standards types: basic data types, considered as atomic or Prior to SQL:1999 there was no support of user- intrinsic and extendible by users as distinct types, defined types, collection, typed tables and other abstract data types (with their own components or featured which today are included under object- attributes, identity, inheritance, polymorphism) and relational label. As response to the pressure of collection types (row type, list type, set type, multiset application developers and threatening ODMG type). These categories of types are primary used in language OQL, soon after SQL-92 publication, the defining the types of attributes from tables’ headings. people involved in SQL standards started adding Consequently, we can try to find the counterpart new options. According to Melton [16] SQL:1999 elements of scalar data types of The Third Manifesto introduced SQL Object Model which has two in specifications of abstract data types:

Communications of the IBIMA Volume 9, 2009 ISSN: 1943-7765 50 Marin Fotache and Cătălin Strîmbei

• Observer functions can be considered an one subtype value that equivalent of read only operators; satisfies an subtypes • Mutator functions can be considered an special constraint too) equivalent of update operators; IM Prescription 14, 15 SQL conform thanks to • Constructors functions ca be used as – TREAT DOWN TREAT AS and TYPE (X) selector operators; operator and type [IS] OF (t) expressions • Possible representation components will testing be (unfortunately, only in a larger sense) IM Prescription 16 – SQL conforms as attributes of public interface associated Read-only operator with the abstract data type. inheritance and value substitutability Date and Darwen had made a detailed analysis on IM Prescription 17 – SQL conforms SQL conformance with their prescriptions, Operator signatures proscriptions and suggestions; the main IM Prescription 18 – SQL conforms conclusions of them can be summarized as in Table Read only parameters 1. to update operators IM Prescription 19 – SQL fails, it require update Table 1. Date&Darwen Analysis of SQL Standards Update operator operators to be inherited RM Prescription 1 – SQL conforms, with some inheritance and variable unconditionally (lack of Scalar types (possible observations about substitutability type constraints) representations, constructor function which selector operators) in reality initialize an So, even with the lack of type constraints and the allocation storage and not consequences of this, SQL:1999, SQL:2003, and select an arbitrary value SQL:2008 standards acceptable support the scalar from a domain type as they are stated in The Third Manifesto. RM Prescription 3 – SQL conforms with Scalar operators observers and mutators RM Prescription 4 – SQL require indeed a type 6. Oracle Object-Relational Features Actual vs. possible representation based on Oracle is one of the best database products, not only representation individual attributes but as SQL dialect and database logic application does not explicitly language (PL/SQL), but also as O-R features. Since differentiate internal and Oracle 8i version, new options have been added in external representation order to work more naturally with objects. Oracle RM Prescription 5 – SQL conforms mostly does not use the term class , but type . Similarly to Expose possible because each attribute packages, every type has a (public) header and a representation (equivalent with a (private) body. The next example creates the UDT component from type as value which is useful in managing addresses: representation) definition automatically causes CREATE OR REPLACE TYPE all_addresses_type AS OBJECT ( definition of one observer numb NUMBER(3), method and one mutator street VARCHAR2(50), method zipcode NUMBER(6), RM Prescription 23 – SQL conforms with respect city VARCHAR2(25), Integrity constraints to attribute, relvar and county VARCHAR2(25), database constraints, but MEMBER FUNCTION getNumb RETURN NUMBER, fails completely with MEMBER FUNCTION getStreet RETURN VARCHAR2, respect to type constraints MEMBER FUNCTION getZipCode RETURN NUMBER, MEMBER FUNCTION getCity RETURN VARCHAR2, IM Prescriptions 1 – SQL Conforms MEMBER FUNCTION getCounty RETURN VARCHAR2, types are sets MAP MEMBER FUNCTION ordering RETURN VARCHAR2 IM Prescriptions 2 – SQL Conforms ) NOT FINAL NOT INSTANTIABLE subtypes are subsets / IM Prescriptions 8,9 – SQL Conforms ------scalar values and scalar CREATE OR REPLACE TYPE BODY all_addresses_type AS variables with ------inheritance MEMBER FUNCTION getNumb RETURN NUMBER IS IM Prescription 10 – SQL fail completely BEGIN Specialization by because of lack of type RETURN SELF.numb ; constraint (subtypes constraints END getNumb ; values satisfies ------supertypes constraints, ... but shall exist at least ------MAP MEMBER FUNCTION ordering RETURN VARCHAR2 IS Communications of the IBIMA Volume 9, 2009 ISSN: 1943-7765 Object-Relational Databases – An Area With Some Theoretical Promises and Few 51 Practical Achievements

BEGIN MEMBER FUNCTION getFirst_name RETURN VARCHAR2, RETURN county || city || zipcode || street || numb ; MEMBER FUNCTION getLast_name RETURN VARCHAR2, END ordering ; MEMBER FUNCTION getAddress RETURN ------all_addresses_type, MEMBER FUNCTION getPhone_numbers RETURN END ; phones_type, / STATIC FUNCTION getWhoOwnsThePhoneNumber (phoneno_ VARCHAR2) RETURN person_type Most of the methods are member functions which ) NOT FINAL can be applied to an instance (object) of all_addresses_type type (class). The type is not When some attributes of a typed table are nested final, so it can have subtypes. It is also (by default) tables, Oracle requires using NESTED TABLE not instantiable. clause in CREATE TABLE statement. As pointed out in previous section, in both SQL standards and Next we introduce a subtype of all_addresses_type, Oracle constraints may be declared only at table called flat_address_type with four new attributes creation (see PRIMARY KEY clause) and not at (properties) and one overwritten method. This type types definition. is associated with flats (apartments) addresses. CREATE TABLE people OF person_type (PRIMARY KEY CREATE OR REPLACE TYPE flat_address_type (personid)) UNDER all_addresses_type ( NESTED TABLE phone_numbers STORE AS building_name VARCHAR2(30), phone_nos_nt floor VARCHAR2(10), apartment NUMBER(4), Now, the table being created, the type body may be MEMBER FUNCTION getBuilding_name RETURN declared/compiled: VARCHAR2, MEMBER FUNCTION getFloor RETURN VARCHAR2, CREATE OR REPLACE TYPE BODY person_type AS MEMBER FUNCTION getApartment RETURN NUMBER, MEMBER FUNCTION getFirst_name RETURN VARCHAR2 IS OVERRIDING MAP MEMBER FUNCTION ordering ... RETURN VARCHAR2 ) FINAL STATIC FUNCTION getWhoOwnsThePhoneNumber (phoneno_ / VARCHAR2) RETURN person_type IS v_pers person_type ; CREATE OR REPLACE TYPE BODY flat_address_type AS BEGIN ------SELECT p.object_value INTO v_pers FROM people p MEMBER FUNCTION getBuilding_name RETURN WHERE p.personid IN (SELECT x.personid FROM people x, VARCHAR2 IS TABLE (x.phone_numbers) t ... WHERE t.COLUMN_VALUE = phoneno_ ) ; RETURN v_pers ; OVERRIDING MAP MEMBER FUNCTION ordering END getWhoOwnsThePhoneNumber ; RETURN VARCHAR2 IS BEGIN END ; RETURN county || city || zipcode || street || numb || building_name || Method getWhoOwnsThePhoneNumber is a search entrance || floor || apartment ; method, returning the instance (of person_type ) END ordering ; which has a given phone number. Inserting objects in PEOPLE typed table requires END ; default constructors of every type involved:

Collections used to be one of the main weaknesses INSERT INTO people VALUES of the relational databases. Now it is not the case. (NEW person_type (1109, 'John', 'Doe', In Oracle it is possible to store two types of flat_address_type(22, 'Narowway', 700100, 'Smallcity', collections, nested tables and varrays : 'Smallcounty', 'GreenTower', '24', 546), phones_type ('00330232217000', '00330232217111'))) CREATE TYPE phones_type IS TABLE OF VARCHAR2 (15) Querying tables of objects is similar to “regular” CREATE OR REPLACE TYPE person_type AS OBJECT ( tables. Oracle violates OO encapsulation because personid NUMBER(7), attribute values are extracted not only through type first_name VARCHAR2(30), method invocation, but also in classical SQL way. last_name VARCHAR2(30), Invoking a method which is defined at a subtype in a address all_addresses_type, hierarchy of types is possible using TREAT clause. phone_numbers phones_type, IS OF [ONLY] clause is useful for selecting

Communications of the IBIMA Volume 9, 2009 ISSN: 1943-7765 52 Marin Fotache and Cătălin Strîmbei instances of a certain (sub)type with or without its subtypes. CREATE OR REPLACE TYPE all_addresses_type AS OBJECT ( numb NUMBER(3), Querying nested tables values is possible based on street VARCHAR(50), TABLE clause which converts the collection zipcode NUMBER(6), (nested table) into table rows for which WHERE city VARCHAR(25), predicate could be applied. county VARCHAR(25) ); SELECT p.first_name, p.getLast_Name() AS last_name, p.address.city, The generic data class to implement the type TREAT (p.address AS flat_address_type).getBuilding_name() previously defined will be: AS Build_Name, t.* FROM people p, TABLE (p.phone_numbers) t package javatypes; WHERE p.address IS OF (ONLY flat_address_type) public class CommonAddress { public Long numb; We stop here now, even if there are many other public String street; Oracle O-R features which deserve deeper public Long zipcode; discussions: OIDs, referenced objects, collections public String city; updating, triggers on typed tables, etc. public String county;

7. Native OO platform (Java) implementation public CommonAddress(){} and SQL exposure in Oracle public CommonAddress(Long numb, String street, Long Oracle has a solid foundation of object-relational zipcode, String city, String county) { features, based on notion of OBJECT TYPE. The this.numb = numb; approach presented here exploit a critical feature of this.street = street; Oracle object types: they are callable from SQL this.zipcode = zipcode; DML and DDL statements and can be implemented this.city = city; in independent programming language aside this.county = county; PL/SQL – the implicit procedural database } programming environment, e.g. C, C++, Java (plus any other language that produce byte code runable public Long getNumb() { on DBMS JRE). return numb; } The main drawbacks consist in that although CREATE TYPE and ALTER TYPE syntax is public void setNumb(Long numb) { similar with that established by SQL3, there are this.numb = numb; some notable differences. One of the most painful } shortcomings is the absence of public/private declaration of individual components. This minimal public String getStreet() {...} mechanism would allow to differentiate in some way between possible representations (components public void setStreet(String street) {...} or attributes declared public) and internal representation (components or attributes declared public Long getZipcode() {...} private). public void setZipcode(Long zipcode) {...} To make a practical demonstration of our approach of independently implement data types usable in public String getCity() {...} database declaration as SQL statement, let’s consider the Address type with the number, street, public void setCity(String city) {...} zipcode, city and county attributes and database representation. The SQL3 declaration of such a public String getCounty(){...} type will be: public void setCounty(String county) {...} CREATE TYPE all_addresses_type ( numb NUMBER(3), public String toString(){ street VARCHAR(50), return "Adress: " + this.numb + ", " + this.street + ", " + zipcode NUMBER(6), this.zipcode + ", " + this.city + ", " + this.county; city VARCHAR(25), } county VARCHAR(25) ); }

As we have already seen, the simplified Oracle Java class to be used as implementation of object syntax will be in first form: types has to implement the SQLData interface, a Communications of the IBIMA Volume 9, 2009 ISSN: 1943-7765 Object-Relational Databases – An Area With Some Theoretical Promises and Few 53 Practical Achievements

JDBC interface which is essential in creating Java public static CommonAddressType instance of Oracle DDL object type. So, to conform set_zipcode(CommonAddressType adr, Long zipcode) { to this demand we have to create a second class (or adr.zipcode = zipcode; to modify the original class) that extends the first return adr; one and to implement the interface required: } public static CommonAddressType package javatypes; set_city(CommonAddressType adr, String city) { import java..*; adr.city = city; public class CommonAddressType extends CommonAddress return adr; implements SQLData { } // original Oracle Object Type public static CommonAddressType protected String sql_type; set_county(CommonAddressType adr, String county) { adr.county = county; public CommonAddressType() { } return adr; } public CommonAddressType(Long numb, String street, Long } zipcode, String city, String county) { super(numb, street, zipcode, city, county); The loadjava tool will be the vehicle to “port” these } two classes in the database schema, and the DDL declaration of object type implemented by the public static CommonAddressType create() { CommonAddressType will be as follows: return new CommonAddressType(); } CREATE OR REPLACE TYPE all_addresses_type AS OBJECT EXTERNAL NAME 'javatypes. CommonAddressType' public static CommonAddressType create(Long numb, String LANGUAGE JAVA street, Long zipcode, String city, String county) { USING SQLData( return new CommonAddressType(numb, street, zipcode, numb NUMBER(3) EXTERNAL NAME ‘numb’, city, county); street VARCHAR(50) EXTERNAL NAME ‘street’, } zipcode NUMBER(6) EXTERNAL NAME ‘zipcode’, city VARCHAR(25) EXTERNAL NAME ‘city’, public String getSQLTypeName() throws SQLException { county VARCHAR(25) EXTERNAL NAME ‘county’ return sql_type; } STATIC FUNCTION construct(numb NUMBER, street VARCHAR, zipcode NUMBER, city VARCHAR, county public void readSQL(SQLInput stream, String typeName) VARCHAR) RETURN all_addresses_type throws SQLException { EXTERNAL NAME 'create (java.lang.Long, java.lang.String, sql_type = typeName; java.lang.Long, java.lang.String, java.lang.String) return numb = Long.valueOf(stream.readString()); javatypes. CommonAddressType ', street = stream.readString(); zipcode = Long.valueOf(stream.readString()); STATIC FUNCTION set_numb(adr all_addresses_type, numb city = stream.readString(); NUMBER) RETURN all_addresses_type county = stream.readString(); EXTERNAL NAME 'set_street(javatypes. CommonAddressType, } java.lang.Long)return javatypes. CommonAddressType ',

public void writeSQL(SQLOutput stream) throws STATIC FUNCTION set_street ... , SQLException { stream.writeString(numb.toString()); STATIC FUNCTION set_zipecode..., stream.writeString(street); stream.writeString(zipcode.toString()); STATIC FUNCTION set_city..., stream.writeString(city); stream.writeString(county); STATIC FUNCTION set_county..., } public static CommonAddressType MEMBER FUNCTION to_string RETURN VARCHAR2 set_numb(CommonAddressType adr, Long numb) { EXTERNAL NAME 'toString() return java.lang.String' adr.numb = numb; ) return adr; } With EXTERNAL NAME LANGUAGE JAVA and public static CommonAddressType USING SQLData declarations, DBMS engine will set_street(CommonAddressType adr, String street) { note that CommonAddressType class will be the adr.street = street; back-end of ALL_ADDRESSES_TYPE object type. return adr; So what we can do with this type: we can associate a } table column with it:

Communications of the IBIMA Volume 9, 2009 ISSN: 1943-7765 54 Marin Fotache and Cătălin Strîmbei

Varwig, T.A., An Object-Oriented Relational CREATE TABLE customers Database, Communications of the ACM, 33 (11), (id NUMBER(4), name VARCHAR(30), residence 1990, 99-109. ALL_ADDRESSES_TYPE) [4] Stonebraker, M., Anton, J., Hanson, E. Extending INSERT INTO customers a Database System with Procedures, ACM VALUES (1001, 'Alpha Inc.', ALL_ADDRESSES_TYPE (11, Transactions on Database Systems, 12 (3), 1987, 350- 'Carol 1', 6600, 'IASSY', ‘IASSY’)) 376.

And finally we can try to expose the value type [5] Kim, W., Research Directions in Object-Oriented using and “accessor” function (to_string()) that can Database Systems, Proc. of the ninth ACM SIGACT- implement a convenient “possible representation”: SIGMOD-SIGART symposium on Principles of SELECT c.name, c.residence.to_string() FROM customers c; database systems , Nashville, TE, 1990, 1-15.

[6] Atkinson, M., Bancilhon, F., DeWitt, D., Dittrich, 8. Conclusions and open issues K., Maier, D., Zdonick, D., The Object-Oriented The topic of “post-relational” age in database Database System Manifesto, Proc. of the systems is a generous one. From many directions International Conference on Deductive and Object- that have been proposed, this paper deal with three Oriented Databases , Kyoto, Japan, 1989, 1-17. strands of O-R data model, summarized as follows: • OR Database Systems, asserting extension of the [7] Ullman, J.D. Database Theory: Past and Future, existing relational “infrastructure” by engrafting Proc. of the sixth ACM SIGACT-SIGMOD-SIGART OO generic innovations promoted by semantic data symposium on Principles of database systems , San modeling and application programming Diego, CA, 1987, 1-10. (Stonebreaker, SQL:1999-2008); • Relational database systems with orthogonal OO [8] Lodhi, F, Ghazali, M.A., Design of a simple and features (Date&Darwen), claiming that all effective object-to-relational mapping technique, “traditional” relational theory could remain Proceedings of the 2007 ACM symposium on Applied unaltered; computing , Seoul, Korea, 2007, 1445-1449. • “Pure” OO Database Systems, with no-reference to the existing relational theory, supplying [9] Atkinson, M P., Morrison R. Orthogonally “orthogonal persistence” to the application objects. Persistent Object Systems , VLDB Journal 4 (3), 1995, 319-401 One of the major drawbacks of today O-R applications is the “impedance mismatch” between [10] Kim, W., Observations on the ODMG-93 OO and the relational layers. Much effort has been Proposal for an Object-Oriented Database Language, purported to finding adequate mapping tools ACM SIGMOD Record, 23 (1), 1994, 4-9. between OO classes and relational tables [8] [18] [19]. [11] Leavitt, N., Whatever Happened to Object- Oriented Databases?, Computer, 33 (8), 2000, 16-19. As proved in Sections 5, 6 and 7, both SQL Standard and major database servers have powerful [12] Cattell, R.G.G, Rogers, T.R., Combining Object- options for dealing with all the major aspects of O- Oriented and Relational Models of Data, Proc. of the R model and applications. 1986 international conference on Management of data , Portand, OR, 1986, 78-87. It is sad that, instead of creating types and managing them within O-R tables, and then [13] Stonebraker, M., Rowe, L.A., Lindsey, B., Gray, mapping directly classes in application logic layer J., Carey, M., Brodie, M., Bernstein, P., Beech, D., to typed tables in database layer [8] [20], most of Third-Generation Database Systems Manifesto, ACM the application developers just map classes to SIGMOD Record, 19 (3), 1990, 31-44 relational tables, failing to exploit the strengths of O-R model. [14] Date, C.J., Darwen, H., Databases, types, and the relational model. The third manifesto (Reading, References MA: Addison-Wesley, 2007).

[1] Codd, E.F., A Relational Model of Data for [15] Stonebraker, M., Brown, P., Moore, D., Object- Large Shared Data Banks, Communications of the relational DBMSs: tracking the next great wave (San ACM, 13 (6), 1970, 377-387. Francisco, CA: Morgan Kaufmann, 1999).

[2] Darwen, H., Date, C.J., The Third Manifesto, [16] Melton, J., Advanced SQL:1999. Understanding ACM SIGMOD Record, 24 (1), 1995, 39-49 Object-Relational and other advanced features (San Francisco, CA, Morgan Kaufmann, 2003). [3] Premerlani, W.J., Blaha, M.R., Rumbaugh, J.E., Communications of the IBIMA Volume 9, 2009 ISSN: 1943-7765 Object-Relational Databases – An Area With Some Theoretical Promises and Few 55 Practical Achievements

[17] Seshadri, P., Enhanced abstract data types in object-relational databases, VLDB Journal, 7 (3), 1998, 130-140

[18] Agarwal, S., Architecting Object Applications for High Performance with Relational Databases, OOPSLA Workshop on Object Database Behavior, Benchmarks, and Performance , 1995, available at: http://www-db.stanford.edu/pub/keller/1995/high- perf.pdf

[19] O’Neil, E., Object/relational mapping 2008: hibernate and the entity data model, Proceedings of the 2008 ACM SIGMOD international conference on Management of data , Vancouver, Canada, 2008, 1351-1356.

[20] Vara, H.M., Vela, B., Cavero, J.M., Marcos, E., Model Transformation for Object-Relational Database Development, Proceedings of the 2007 ACM symposium on Applied computing , Seoul, Korea, 2007, 1012-1019.

Copyright © 2009 by the International Business Information Management Association (IBIMA). All rights reserved. Authors retain copyright for their manuscripts and provide this journal with a publication permission agreement as a part of IBIMA copyright agreement. IBIMA may not necessarily agree with the content of the manuscript. The content and proofreading of this manuscript as well as any errors are the sole responsibility of its author(s). No part or all of this work should be copied or reproduced in digital, hard, or any other format for commercial use without written permission. To purchase reprints of this article please e-mail: [email protected] .

Communications of the IBIMA Volume 9, 2009 ISSN: 1943-7765