After having ranted about this in the CB and edan prompting me to make my ranting eternal by means of a post, I call rubbish on the three questions you actually meant to pose:

1. What is an Object Oriented Database?
2. What is Truly Object Oriented?
3. How do the two things relate?

I think that these three questions have no good answers because they are all three very ill defined, at least without further context.

For example, Smalltalk people call other languages "not Truly Object Oriented", if there are things in Other Languages that are not objects, i.e. you can't call methods ("send messages" in Smalltalk-lingo) to them. In that sense, Perl is not Truly Object Oriented, as you can't call a method on an integer. autobox is a hammer to solve this perceived problem. You also can't manipulate classes as if they were objects, which has a "solution" in the form of, for example, Class::Classless. I'm not convinced that these perceived problems are actual problems, but if you're talking to somebody in the Smalltalk camp, they will use that as a line of demarcation between Truly Object Oriented and Providing Syntactical Candy to Seem Object Oriented.

There also is no standard to what databases need to provide to call themselves "Object Oriented". Any database can be called Object Oriented, as long as you restrict what you call your objects to databases, tables, rows and indices. It is an ill-defined and much abused term like "XML databases". Perl has Class::DBI which provides a thin persistence layer for objects into databases, and these two discussions pointed out to me by Super Search go much deeper into the problems and solutions of OODBMS. I don't see much use in these, because if you're going to store arbitrary objects in your database, you have a much larger problem as to what to do with these objects, and if you don't know about your objects, all you will be able to do with them is call a given set of methods on them, operating on them in an iterative fashion, instead of operating on them as a set, like traditional RDBMS do. Then, you are likely either well off using a tied hash to serialize your object data, or using Class::DBI, depending on whether you want to go the extra mile to define a database schema for your objects or just serialize them as blobs.

As I didn't come up with a favourable answer to any of the first two questions, the third won't be answered by me either, at least not in a constructive way - you can always map an "object" to a "data structure" and code that operates on it, like, say, a hash, and a set of functions that all take the hash as the first parameter. So there is not much sense in saying that only a Truly Object Oriented Language can interoperate with an Object Oriented DB. Perl also has enough of introspection and the eval statement so that you can generate classes on the fly, so as long as the database lets you in on the object format, you can create a suitable class for it. Whether that is what was meant, I don't know though.