Object-Relational Databases – an Area with Some Theoretical Promises and Few 47 Practical Achievements

Object-Relational Databases – an Area with Some Theoretical Promises and Few 47 Practical Achievements

Object-Relational Databases – 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 relational model 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 database 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 Hugh Darwen 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

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    9 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us