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
studentstable 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.
enrollmentsmight have each row including a reference to a row of the
studentstable and another reference to a row of the
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.
SELECT section->dept, section->num, grade
WHERE student->name = 'Burch' AND section->dept = 'CSCI'
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.