"This contrasts with both the database and programming language being object-oriented as well as with both the database and language being procedural."

Sounds like there was a little bit misunderstanding of what the author said. As for database, I don't think he is talking about OO database, and most of the databases around us are not. As for language, he is still talking about OO.

His point is how to mapping database tables to objects.

We had some big discussion in our shop about this, and actually the talking is still going on... The problem you facing when you coding in a language like Java is that, the most obvious way of mapping is make each database table a DCO.

Now there is a big issue with this approach: when you create their DAO's, it becomes so unreal for you to enjoy the benefit of table joins, subqueries (we use Oracle, it supports a wide range of SQL statement, which magnified this issue).

We end up with adding two more concepts: ECO (Enterprise Data Container Object) and EAO (Enterprise Data Access Object). When DCO and DAO encapsulate the data and access mothods against a single table. ECO and EAO allow you to encapsulates data from multiple tables. This closely matches what the author called business object. Design wise, this approach allows you to more freely realize objects in its own way, and not held back by database normalization; Practical wise, it allows you to enjoy the power of a wide range of SQL statement, and your code makes more sense.