There are a number of issues raised by your question.
First off, there's only one database involved. Databases can have multiple user schemas, and each connection is to a schema in a database. User schemas can create multiple feature datasets, which are not equivalent to databases (your problem description is very confusing in this regard, since "owner", "user", and "database" seem to have different than the conventional definitions).
Each connection, in addition to all the tables that a given user can see, will see ALL the feature datasets in the geodatabase instance. This is because, unlike tables, feature datasets are artificial constructs in the SDE.GDB* table metadata. There is no efficient way to determine the contents of a feature dataset before it is opened, so they are all listed (unexploded), and upon open, if you do not have at least SELECT access to every table listed in the metadata, the object will show as empty. This is a design feature of feature dataset behavior; it's not likely to change (at least, it hasn't changed in the past seven releases dating back to 9.0).
Feature datasets were never intended to be used as "folders" for organizing data. Their purpose has always been to permit cooperative editing across feature classes (e.g., utility lines and poles and transformers). There are a number of significant performance issues with using feature datasets as logical organization tools, and documentation, training, user conference workshop slides, and forums are filled with exhortations to NOT use feature datasets for this purpose. I empathize with those who find organizing hundreds of tables in a flat RDBMS representation cumbersome, but that's the paradigm for RDBMS access, established many moons ago, so it doesn't seem to be changing either.
There is a means for isolating user data in Oracle geodatabases, but user-schema geodatabases are, IMHO, a treatment which is far worse than the disease. You should carefully review the restrictions on interactions of user-schema tables with those of other user-schemas before beginning down this path. There are also significant performance penalties associated with using more than a few user-schema instances in a single Oracle instance. All in all, I'd suggest that you wait until ArcGIS supports multi-tenant Oracle 12c instances the way it supports the non-Oracle RDBMS implementations, with true isolation between instances.