As an example of such a privately managed database, consider a print service where jobs are submitted not to individual printers, but rather to a generic printer service. The client, lpr, binds (probably through a group entry) to some certain print server, and sends the job to be printed to that server, which then, after some thought, sends the job to one of the printers that it manages.
Consider, for example, what happens if a user invokes the client cancel sometime later to stop a job. If, for example, the original command was
lpr War_and_Peace.ps
and the subsequent request to cancel is
cancel War_and_Peace.ps
then how does the server that cancel binds to find the right job to delete? There is no guarantee that cancel will bind to the same server that happened to receive the original print request, so having each print server keep track of its own jobs would not be the answer.
One way to keep track of jobs queued would be to have a dedicated job location server as part of the application. Each time a print server queued a job to a printer it would record the fact (with all the pertinent details) with the location server. Whenever a job completed, the server would again notify the location server to remove its record of that job from its database. A client cancel then binds first to the location service, where it receives the name of the print server associated with the job it wants to cancel. It then looks up that name, binds to the right print server, and sends the cancel request. In effect, the location server has become a name service for cancel.
This method of organizing activity results in a split-model database. The print servers' binding information is managed through CDS, as usual, and the location server manages other more volatile information associated with those same servers.
Another way a server could maintain its own database of named objects would be by implementing a junction.