Su pregunta plantea varias cuestiones.
En primer lugar, sólo hay una base de datos implicada. Las bases de datos pueden tener múltiples esquemas de usuario, y cada conexión es a un esquema en una base de datos. Los esquemas de usuario pueden crear múltiples conjuntos de datos de características, que son no equivalentes a bases de datos (la descripción de su problema es muy confuso a este respecto, ya que "propietario", "usuario" y "base de datos" parecen tener definiciones distintas de las convencionales).
Cada conexión, además de todas las tablas que puede ver un usuario determinado, verá TODOS los conjuntos de datos de características de la instancia de geodatabase. Esto se debe a que, a diferencia de las tablas, los conjuntos de datos de características son construcciones artificiales en los metadatos de la tabla SDE.GDB*. No existe una forma eficaz de determinar el contenido de un conjunto de datos de características antes de abrirlo, por lo que todos aparecen en una lista (sin explotar) y, al abrirlo, si no se tiene al menos acceso SELECT a cada en los metadatos, el objeto aparecerá vacío. Se trata de una característica de diseño del comportamiento de los conjuntos de datos de características; no es probable que cambie (al menos, no ha cambiado en las últimas siete versiones que se remontan a la 9.0).
Los conjuntos de datos de características nunca se concibieron como "carpetas" para organizar datos. Su finalidad siempre ha sido permitir la edición cooperativa de distintas clases de características (por ejemplo, líneas y postes de servicios públicos y transformadores). El uso de los conjuntos de datos de características como herramientas de organización lógica plantea una serie de problemas de rendimiento importantes, y la documentación, la formación, las diapositivas de los talleres de las conferencias de usuarios y los foros están llenos de exhortaciones a NO utilizar conjuntos de datos de características para este fin. Empatizo con quienes consideran engorroso organizar cientos de tablas en una representación RDBMS plana, pero ese es el paradigma de acceso RDBMS, establecido hace muchas lunas, así que tampoco parece que vaya a cambiar.
Existe un medio para aislar los datos de usuario en las geodatabases Oracle, pero geodatabases de esquema de usuario son, en mi opinión, un tratamiento mucho peor que la enfermedad. Deberías revisar cuidadosamente las restricciones sobre las interacciones de las tablas de esquemas de usuario con las de otros esquemas de usuario antes de empezar por este camino. También hay importantes penalizaciones de rendimiento asociadas al uso de más de unas pocas instancias de esquemas de usuario en una única instancia de Oracle. En definitiva, le sugiero que espere hasta que ArcGIS admita instancias multiusuario de Oracle 12c del mismo modo que admite las implementaciones RDBMS que no son de Oracle, con un verdadero aislamiento entre instancias.
