I have long been a fan of Fabian Pascal's database ramblings (not his political and economical ones, the man has absolutely no clue on those). Yes, the relational theory is actually set algebra, and therefore a relational database is the most complete and powerful type of database, bar none. Object databases, hierarchical databases (registry), network databases (objects) - they all have problems which simply do not exist in an RDB.
However, I was re-reading an article about the object / relational mismatch problem - Interoperability happens and I got to this part:
Developers simply give up on relational storage entirely, and use a storage model that fits the way their languages of choice look at the world. Object-storage systems, such as the db4o project, solve the problem neatly by storing objects directly to disk, eliminating many (but not all) of the aforementioned issues; there is no "second schema", for example, because the only schema used is that of the object definitions themselves. While many DBAs will faint dead away at the thought, in an increasingly service-oriented world, which eschews the idea of direct data access but instead requires all access go through the service gateway thus encapsulating the storage mechanism away from prying eyes, it becomes entirely feasible to imagine developers storing data in a form that's much easier for them to use, rather than DBAs.
So... an application could simply forget about the whole database thing and completely take over the storage and management of objects. It can also handle the problem (mentioned in that article) of other parts of the same enterprise wanting to use the data by exposing it through services, so that nobody can have access to the underlying objects (and thus nobody needs to change their own application if this application is refactored). True, such an "object database" lacks a lot of the powerful advantages of a relational one, like ad-hoc querying - but maybe for this application, You Ain't Gonna Need It.
Interesting idea. I think I read somewhere that Robert Martin starts what are to everyone else obvious database applications by ignoring that part... because he might not need a database after all, and he definitely does not need it to start with. I never understood that until now :)