What it is about the OOP paradigm that you find does not fit this client->relational database application? The idea behind OOP is that you send a message out into the world, and maybe another actor can make something of it. You don't really know or care about the other actors are out there. If an actor hides a relational database behind closed doors, so be it. Not your problem. That's outside of the concern of OOP.
On the flip side, we have active record, which imagines a way to try and marry relational databases to an object-based (not oriented) model. Here you will regularly find criticism about "impedance mismatch" and where things like constraints should be handled. This still reads like what you are talking about, but has little to do with OOP.
Conceivably you could use that pattern to implement the local retention of an actor. Is that where you find applicability to OOP? OOP doesn't speak to the underlying actor implementation, though. It purposefully doesn't speak to the implementation as not having knowledge of actors is kind of OOP's whole deal. If you need to know things about other actors, you can't just throw a message out there.
Because of the similar names, those who don't understand OOP oftentimes confuse it with object-based programming. Perhaps this is what you are trying to speak to, using a 'database layer' as an example of object-based programming as seen in the wild?
Admittedly, I still don't fully understand the link you are making between relational databases and OOP.