Object Capabilities in Databases
The article describes the emerging object capabilities that are being provided in database management systems. Traditional relational databases and object oriented databases are compared first. Next, reasons that object oriented databases have failed to garner substantial market share are presented. The capabilities provided by the new relational (or object relational) databases are then presented.
The major topics in this article:
In the late 1980s, the distinction between relational database management systems (RDBMS) and object oriented database management systems (ODMBS) was stark. Most RDBMS's allowed you to store simple data types (character, numeric, date) but you could not automatically trigger actions or store complex data types. By contrast, an ODBMS allowed you to store complex data types and perform operations on such data.
By the early-to-mid 1990s, most major RDMBS's had added some very basic object features in the form of triggers and binary large objects (or BLOBs). A comparison of the typical RDBMS and ODBMS prior to 1997 is given in Table 1.
Table 1: Typical RDBMS and ODBMS features prior to 1997
|Relational Databases (RDBMS)||Object Oriented Databases (ODBMS)|
|complex data types||- supports binary large objects (BLOBs) which
are essentially very large database columns
- database columns must generally be simple data elements, rather than structures and arrays
|- supports complex data types, including user defined data types|
|locating data||- fast at locating simple data types
- no support for searching or indexing BLOBs
|- usually slower than RDBMS when locating
simple data types
- sophisticated algorithms used to search for data within complex data types
|language standards||- Major RDBMS's use a standard language (SQL2 / SQL92) with vendor-specific extensions. SQL is both a data definition language (DDL) and a data manipulation language (DML).||- Many ODBMS's support object query language
(OQL) and object definition language (ODL) which are part of the larger Object Data
Management Group (ODMG) standard. There are varying degrees of compliance amongst ODBMS
vendors with the overall ODMG standard.
- unlike RDBMS's which use SQL Insert, Update, Delete, data manipulation is performed in the programming language by invoking methods on the object -- this allows for better object encapsulation.
methods on DBMS
|- provides triggers / stored procedures which
are written in the native DBMS language
- function / method inheritance not supported
|- object methods are typically written in a
selected OO programming language (usually C++, Java or Smalltalk)
- object/method inheritance is supported
Prior to 1997, ODBMS had a clear technical advantage in providing object capabilities.
Limited Presence of Object Oriented Databases
Almost a decade after their introduction, ODBMS's account for about 3% of the overall database market and their market share is growing. The lack of significant market presence could explain why major client/server tools (e.g. PowerBuilder, Visual Basic) do not yet operate directly with ODBMS's.
Traditional weaknesses that have held back ODBMS's include:
To date, the benefits of an ODBMS have not justified the costs of a revolution in data storage for most companies.
Emerging Requirements for Object Database Capabilities
ODBMS vendors inability to gain a significant market presence is not a sign that object capabilities are not needed. In fact, the requirement for more object features in databases is increasing due to the following underlying trends in application development:
Most companies that want to obtain the object features are more comfortable with the evolutionary approach provided in the new offerings from the RDBMS vendors. The new databases are called Object Relational Database Management Systems (ORDBMS) or universal servers. These new databases add features which augment existing relational capabilities. In doing so, they provide a number of the key object features that are in demand.
Important features provided in the new ORDBMS's are outlined below.
User Defined Types: User defined types (UDTs) let the developer define their own data types and create columns of those types. Sample UDTs include structures, arrays, text, multimedia, time-series, etc.
User Defined Functions: User defined functions (UDFs) are defined methods for manipulating data. UDFs can be invoked independently or inside a SQL statement (e.g. in the WHERE clause). UDFs can usually be overloaded to take different numbers and types of arguments. UDFs usually operate on complex data (i.e. UDTs). A UDF might decompress a video image or extract a desired date range from time-series data.
Extended Search/Index Capabilities: Some ORDBMS's provide the ability to search complex data types, which is a notable improvement on the opaque BLOBs which came earlier. The new ORDBMS's are starting to provide the capability to specify the "cost" of searching UDTs or executing UDFs to better optimize queries that involve complex data. Accurate query optimization will be key to obtaining good performance in applications that make extensive use of complex data types.
Predefined Extensions: The ORDBMS vendors are offering a number of predefined extensions (called DataCartridges by Oracle, Snapins by Sybase, DataBlades by Informix). Each extension handles complex information in a particular application domain such as text search, images, video, messaging, etc. Some of these extensions are provided by the vendors themselves and others are being written by third parties.
Extended Support for Programming Languages: Functions in traditional RBDMS's had to be written in the database vendor's native language (e.g. PL/SQL in Oracle, T-SQL in SQL Server, SPL in Informix). ORDBMS are now providing support for C, C++ and Java when writing UDFs in their databases.
Many of the common extensions being provided by the new ORDBMS's are being included in the new SQL3 standard. SQL3 includes support for UDTs, UDFs, hierarchies of types and inheritance in these hierarchies and SQL/Multimedia.
Early users of the new ORDBMS's will need to carefully consider which object-relational extensions to use. Some of the new object-relational extensions (e.g. complex data types) are not yet compatible with all the existing database features like data replication and distributed databases.
Will object oriented databases (ODBMS's) grow and displace the dominant relational databases? This seems very unlikely now. ODBMS did not make a breakthrough in the market in the early-to-mid 1990s when they had the clear technical edge in object capabilities. With the relational vendors closing the object capability gap, it is difficult to see a large number of customers opting for ODBMS's now. It appears likely that ODBMS will likely continue to serve niche markets, as they do today.
... back to Architecture Topics