Object database

Categories: Databases | Database management systems

An object database is a database in which information is represented in the form of objects. The database management system for an object database is referred to variously as a ODBMS or OODBMS.

There are two main factors that lead users to adopt object database technology. Firstly, a relational database becomes cumbersome to use with complex data. Secondly, data is generally manipulated by application software written using object-oriented programming languages such as Delphi, C++ and Java, and the code needed to translate between this representation of the data and the tuples of a relational database can be tedious to write, and time-consuming to execute. This mismatch between the models used to represent information in the application programs and the database is sometimes referred to as an impedance mismatch.

1 Adoption of object databases
2 Technical features
3 Advantages and disadvantages
4 Standards
5 See also
6 Commercial Vendors
7 Open source
8 External links

[edit]

Adoption of object databases

Object databases became a popular subject for academic researchers and start-up companies in the early 1990s. There have been a number of different approaches: some have tried to add the concept of persistence to existing or newly-designed programming languages, while others have tried to add object concepts such as encapsulation and inheritance to existing database concepts. Systems in the latter category, because they retained a declarative query language based on predicate calculus as a central component of the architecture, came to be referred to as object-relational databases (a term due to Michael Stonebraker), or hybrid databases.

Object databases based on persistent programming acquired a niche in application areas such as engineering and spatial databases, telecommunications, and scientific areas such as high energy physics and molecular biology. They have made little impact on mainstream commercial data processing, though there is some usage in specialized areas of financial services.

The ideas (and vendors) of object-relational databases have largely been absorbed by the existing relational vendors in the form of enhancements to their SQL-based products, though some independent object-relational products survive.

Starting in 2004, object databases have seen a second growth period, when open source object databases emerged, that were widely affordable and easy to use, because entirely written in OOP like Java or .NET.

[edit]

Technical features

In a pure object database, data is stored as objects which can be manipulated only using the methods defined for the class to which the object belongs. Objects are organized into a type hierarchy (sometimes a lattice), and subtypes inherit the characteristics of their supertypes. Objects can contain references to other objects, and applications can therefore access the data they require using a navigational style of programming.

Most object databases also offer some kind of query language, allowing objects to be found by a more declarative programming approach. It is in the area of object query languages, and the integration of the query and navigational interfaces, that the biggest differences between products are found.

Access to data can be faster because joins are often not needed (as in a tabular implementation of a relational database). This is because an object can be retrieved directly without a search, by following pointers.

Another area of variation between products is in the way that the schema of a database is defined. A general characteristic, however, is that the programming language and the database schema use the same type definitions.

Multimedia applications are facilitated because the class methods associated with the data are responsible for its correct interpretation.

Many object databases offer support for versioning. An object can be viewed as the set of all its versions. Also, object versions can be treated as objects in their own right. Some object databases also provide systematic support for triggers and constraints which are the basis of active databases.

[edit]

Advantages and disadvantages

Benchmarks between ODBMSs and relational DBMSs have shown that ODBMS can be clearly superior for certain kinds of tasks. The main reason for this is that many operations are performed using navigational rather than declarative interfaces, and navigational access to data is usually implemented very efficiently by following pointers.

The things that work against ODBMS seem to be the lack of interoperability with a great number of tools/features that are taken for granted in the SQL world including but not limited to industry standard connectivity, reporting tools, OLAP tools and backup and recovery standards. Additionally, object databases lack a formal mathematical foundation, unlike the relational model, and this in turn leads to weaknesses in their query support.

In fact there is an intrinsic tension between the notion of encapsulation, which hides data and makes it available only through a published set of interface methods, and the assumption underlying much database technology, which is that data should be accessible to queries based on data content rather than predefined access paths.

Although some commentators have written off object database technology as a failure, the essential arguments in its favour remain valid, and attempts to integrate database functionality more closely into object programming languages continue in both the research and the industrial communities.

[edit]

Standards

The Object Database Management Group (ODMG) was a consortium of object databases vendors set up to create a standard. It published several versions of its proposals (notably ODMG 2.0) but it did not result in interoperable implementations, even from the companies who developed the specification. The failure to establish standards is one of the factors often cited as contributing to the failure of object databases to establish a significant share of the database market. ODMG was disbanded in 2001.

On the object-relational front, many object database ideas were absorbed into SQL 1998, though that too has yet to be consistently implemented.

In 2005 Cook, Rai, and Rosenberger proposed to drop all standardization efforts to introduce additional object-oriented query APIs but rather use the OO programming language itself, i.e., Java and .NET, to express queries. As a result, Native Queries emerged. Similarly, Microsoft announced Language integrated query (LINQ) and DLINQ in September 2005, to provide close, language-integrated database query capabilities with its programming languages C# and VB.NET.

[edit]