Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
26Activity
0 of .
Results for:
No results containing your search query
P. 1
Object Database Management Systems

Object Database Management Systems

Ratings: (0)|Views: 504 |Likes:
Published by dantubb

More info:

Published by: dantubb on Aug 22, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

12/11/2010

pdf

text

original

 
1
Object Database Management Systems: An Overview
 Akmal B. Chaudhri
1
The City University, London"Consider all the classes that are not members of themselves, such as the classof dogs, which is not itself a dog, and try to combine them into a big class of their own, the class of classes that are not self-members: then you have theresult that this class is a member of itself only if it is not and is not only if it is.Contradiction! Red Alert!"
(Russell Paradox)Advertisement for London Review of Books, London Underground.
Abstract
The aim of this paper is to provide a broad overview of Object Database ManagementSystems (ODBMSs). It discusses the shortcomings of existing database technology to meetthe requirements for "next-generation" applications that require support for richer data typesand complex structures. Object and data management requirements for ODBMSs are alsobriefly reviewed. Six major classification models are presented including
 Data Models
,
 Architectures
,
Storage Server Models
,
 Alternative Object Database Strategies
,
 Language Data Models
, and
 Evolution versus Revolution
. Areas for standards are briefly consideredand, finally, the main strengths and weaknesses are discussed.
1. Introduction
The object paradigm has been applied to programming languages, user interfaces, designmethodologies, operating systems, hardware architecture, and database systems. This hasbeen prompted by the desire to control complexity and harness the expanding systemenvironment (e.g. multimedia information, end-user computing, distributed processing) intomore useful and exciting applications [Winbl90]. These "next-generation" applicationsinclude (the often cited) Computer Aided Software Engineering (CASE), ComputerIntegrated Manufacturing (CIM), Computer Aided Instruction (CAI), Computer AidedPublishing (CAP), and other (CAx) applications.For several years now, there has been intense research activity in many of these areas,resulting in the publication of numerous articles and papers. As a result of this research,many new products have also appeared.Within the field of databases, some authors have also noted that the "everything withobjects" approach has been permeating the research and commercial database community.This has resulted in articles such as "My Cat is Object-Oriented" [King89]. 
1
Present address: Systems Architecture Research Centre (SARC), Computer Science Department, The CityUniversity, Northampton Square, London EC1V 0HB, United Kingdom, (email: akmal@cs.city.ac.uk).
 
2It has been noted that there are difficulties in using existing relational technology for thesenew applications areas:
"Everyone agrees that traditional relational database systems do great onbusiness data processing, and lay an egg if you ask them to do anything else... If you want them to store documents or CAD-related information, they just don’t do very well."
Michael Stonebraker, cited in [Hazza90]
"You can do anything with an RDBMS that you can with an OODBMS, except  you have to roll your own."
Mark Hanner, cited in [Hodge89][Codd92] has suggested that relational technology can form the
 foundation
for these newapplication areas. This may be possible with extended relational (or non-first normal form)models, which provide better support for complex data by allowing column attributesthemselves to be vectors (arrays, lists, tables). However, it is difficult to see how thesemantics of multimedia data types (for example) can be adequately captured by therelational model, since it cannot support this type of complex data - largely a by-product of relational theory according to [Hazza90].Object Database Management Systems (ODBMSs), also variously referred to as Object-Oriented Databases (OODBs), Object-Oriented Database Management Systems (OODBMS)or Next-Generation Database Systems, try to address some of the shortcomings of existing(relational) database technology. Briefly, some of these shortcomings are now discussed.
1.1 Lack of Expressive Power
The only data structure (aggregate or object) in the relational model is the table. This reducesall data to flat two-dimensional form, with relationships between tables being dynamicallyre-imposed at run-time. The lack of a facility for establishing relationships between tables atdesign time is probably the main backwards step from the structured database [White89].[Khosh90a] have also noted that the
"semantic eloquence of complex object composition islost"
when real-world objects are mapped to tables, resulting in the so-called "semantic gap."
1.2 Simple Data Types
To support next-generation applications a richer set of data types is required (e.g. arrays,lists, multimedia data types).Some popular RDBMS vendors have enhanced their products to support new data types[Compu91b]. Examples include INGRES that allows the incorporation of user-definedAbstract Data Types (ADTs) into database tables. However, these enhancements are still notcomparable to the facilities provided by Extended Relational Database Systems such asPOSTGRES [Rowe90; Stone90; Stone91].
1.3 Loss of Data Protection
Most RDBMSs support simple data types (e.g. integer, char). Many programming languages,however, enable new enumerated types to be defined. When these enumerated types need tobe mapped to the database types, data protection is lost [Hughe91].
 
3
1.4 Impedance Mismatch
"Impedance mismatch ... the metaphor comes from the field of electricalengineering, and refers to the fact that an impedance mismatch in anelectrical circuit will prevent the maximum power transfer from beingachieved."
[Gray92]Mapping data structures between programs and the database can account for a considerableamount of code - figures of up to 30% have been suggested [Atkin83]. There are severalreasons why this mapping is necessary.Firstly, SQL is relationally complete (it supports the operations select, project and join), butis computationally incomplete (in the sense of a programming language such as C, Pascal,etc.).Secondly, computer programming languages such as C, Pascal, etc. are procedural andrecord-oriented, whilst database query languages such as SQL are more declarative and set-oriented.Thirdly, computer programming languages support rich data types (e.g. arrays) whilst SQLis a closed language, operating on two-dimensional tables with simple types (e.g. integer,char).This mix of paradigms (SQL and host language) results in this "impedance mismatch."However, the mismatch aside, some attempts have been undertaken to extend SQL toprovide more functionality and support for object concepts. Examples include IntelligentSQL [Khosh90b], Objects in SQL [Beech90], and the current efforts of the ANSI X3H2committee (SQL3).
1.5 Performance
Within the literature, it is widely accepted that certain classes of applications are particularlywell suited to ODBMSs (the ubiquitous CAD, CAM, CIM, GIS, Multimedia, etc.). These areprimarily applications involving the storage and manipulation of complex and heavily inter-related data. Traditionally, RDBMSs have been unable to provide the necessary performancefor applications with complex relationships and multi-way joins, as discussed by [Maier89].By its very nature, the relational model "flattens" entities. Putting these entities together in ameaningful way requires joining (described as "unnatural" in [Khosh90a]) and sorting. Theseoperations compete for being the slowest in relational systems [Loomi92]. In addition,commercial language optimisers are often unable to cope effectively with queries involvinglarge numbers of joins [Gray92], which has resulted in static binding strategies beingdeveloped by some relational database vendors (e.g. IBM’s DB2).In many ODBMSs, the equivalent of relational joins are "pre-computed" through the use of explicit pointers. Additionally, since ODBMSs can store methods, this incrementalknowledge about the operations being performed provides the ability to better control theconcurrent execution of transactions (and hence provide better performance). This is possible

Activity (26)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads
aidenandandrew liked this
aidenandandrew liked this
Kartik Thakkar liked this
jayavardhankoti liked this
zoom2mahesh liked this
asuarun4 liked this
Bali Khurana liked this

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->