Database scoping

I've been struggling with the concept of database scope for some time now and I think it's time to put some resulting thoughts down, a) because it will force me to formalize them somewhat, b) so they do not get lost in shuffle of my thoughts, and c) to hopefully build a base upon which myself and others might build.
Before starting, I must admit that I have done no formal research in this area and for all I know there is an entire body of research already encompassing these ideas. That said, I have not seen such a field of research, and so conclude that if there is a body of material that covers these matters, it is obscure and should be brought forth. These "thoughts" could easily turn into a book, so I will probably distribute this over several posts. I'll start in this post by defining the problem.
The problem is that of applying database principals and specifically the relational model beyond the scope of a "shared databank" or Database Management Systems (DMBSs) as we have come to know them. Many of the ideas surrounding such systems assume (and appropriately so) a central, monolithic set of data that is manipulated, analyzed and shared between users. The systems provide extensive services to users by providing an abstract "data model" which serves as the bases for the operations that the system performs. In this approach, however, the logic system embodied in the "data model" can only be used within the DMBS leaving the rest of the application logic to reside in other logic systems. This "other" logic system is usually that of a third generation language (3GL), perhaps augmented by a "component toolset".
Let me remind the reader of the many benefits of maximizing declarativeness in application development and data management, such as fast development, enhanced quality, and agility to change. It is therefore desirable to bring the highest degree of declarativeness to the entire application, not only the portion of the application involving shared data access. Because of this, the most we could ever hope to achieve in the pursuit of the perfect DBMS is the enhancement of one portion of the overall application.
To this end, we should seek a single logic system (I'll avoid the term Data Model as it may narrow our thinking) that can be used for data management and application development within a DBMS as well as without. At first glance at least one portion of the Relational Model seems not to fit if taken beyond DBMS architecture, namely the Information Principal. This principal states that all data ultimately resides in a named set of relations (tables). This leads to other questions: What would it be like for the server and the client to be relational? What would a relational operating system be like? I would like to explore such questions.