Object-Oriented Databases

Traditional database models:

  1. hierarchical
  2. network
  3. relational (since 1970, commercially since 1982, works!)

Object-Oriented data models started mid-1990s

  1. we wanted more complex apps (storing more than numbers and text)
  2. we wanted more data modeling features
  3. increased OOPL use sparked OO database desire

Commercial OODb products came up in 1990s, didn’t really hit mainstream: relational model works well enough, very entrenched

OOPLs: Simula, Smalltalk, C++, Java

Experimental OODb systems: Postgres, IRIS Orion, OPen-OODB

Commercial OODB products: Onotos, Gemstone,…

OODB about maintaining direct correspondence between real-world objects and database objects so objects do not lose their integrity and identity and can easily be identified and operated upon.

Object has state (value: what the object knows) and behavior (operations: what the object knows how to do)

OO captures complex structures in simpler abstract containers or names or nouns.

OODB has objects of arbitrary complexity; traditional database can scatter data about a gievn object across numerous records/tables or records.

OOPL defines instance variables (data members in C++) which hold the values that define the object in a given state.

Two parts of operation:

  1. Signature/Interface of operation specifies operation name and arguments (or parameters)
  2. Method/Body specifies implementation of operation — that’s the instructions.

Polymorphism here refers to the ability of an operation to be applied to different types of objects; a.k.a. operator overloading

Every object has a unique object identifier, the OID. This is tricky if you have a big system with multiple machines/users creating multiple objects simultaneously. However you do it, OID should not change (like in real world: individuals don’t change identity! You are always Bob!).

Every object is a triple: (OID, type, value)

Object types:

  1. atom: single value
  2. set: several values
  3. tuple: like line in database
  4. list: ordered set
  5. bag: collection of objects
  6. set: bag with no duplicates

OODB market growing very slowly; OO ideas being used in many apps but not going to full-tilt OODB.

Ultimately, making the computer’s representation of reality match ours does not matter: databases are a matter of efficient and effective storage. If the computer thinks in terms of relational tables and I think in terms of objects, it doesn’t matter, as long as I get the data I want.

Chapter 22: Object-Relational and Extended Relational DBS

SQL3 added object-relational capacity

We usually don’t see the O in the object-relational database systems; vendors just slap on some object capabilities and don’t sweat calling it a whole different system.

The big push for object capabilities is new media, using audio, video, images, BLOBs. But these big files didn’t really drive the development/adoption effort. RDB folks were already finding ways to deal with those big chunks of data. ODB thinking came about because folks were using OO thinking for other problems (programming, which itself went OO because developers were using OO thinking in planning/design!).


Last word: Database administration is a service industry! We and the stuff we are in charge of have no intrinsic value! We are valuable only to the extent we help out clients figure out what they need and optimize what they do. We serve our clients.