Object-relational database systems

With the rise of object-oriented programming languages came a push to include the same object-oriented features in databases. Several object-oriented DBMSs have been designed.

Ultimately, though, the vendors of major relational DBMSs were able to include much of the functionality in their existing relational systems, and they've pretty much won out. Since their hybrid systems that don't exactly match the ideals of an object-oriented DBMS, they are called object-relational database management systems (ORDBMSs). Examples of ORDBMSs include PostgreSQL and Oracle (and, to a lesser extent, Microsoft's SQL Server).

Distinguishing features of an ORDBMS relative to an RDBMS:

• Support for aggregate types like sets, lists, and structs. For example, each row of a students table could include a column named contacts, which contains a list giving names, relationships, and phone numbers. This would be impossible in a purely relational system.
• Methods can be associated with a row.
• References allow for direct references between tuples — essentially pointers, except that the tuples are actually store on disk. Rather than using the primary key of a table to identify a row, we can use this reference instead. A table enrollments might have each row including a reference to a row of the students table and another reference to a row of the sections table.

The 1999 version of the SQL standard added some support for object-relational concepts. As an example, in this system we might have a query that looks like the following.

In a relational system, we would need to join three tables together, but here using the references as pointers allows for a query that's arguably simpler. This might come at the cost of efficiency, since it may prevent the DBMS from using some very efficient joins — but quicker development time may make this worthwhile.