There are different answers to different aspects of this question, mostly because of the paradigm shift from table-wise thinking to graph-wise thinking, as Fred already said.
Some simple statements:
One MicroStream database always has exactely one root object.
One application can have an arbitrary number of MicroStream databases (= StorageManager instances).
(But beware of mixing references between them, since references handling, lazy references, etc. will get mixed up and create inconsistencies)
One root object can point to an arbitrary number of object graphs. Each one is then simply a sub graph of the whole graph.
We have a customer project that has to handle 3 clients internally in the same application.
So they are technically 3 databases with the same structure but different data.
3 object graphs with one root object each.
How to handle that with just a single root object?
A superordinate "clients" collection points to the 3 client-roots.
This pattern holds for any number of graphs and any level of complexity.
You can always add another "layer" of nodes in your graph and thus combine multiple (sub-)graphs referenced by a single superordinate root, thus creaing a new super-graph that points to everything else. Without any overhead in performance or memory to speak of.
This is a completely different thinking from designing data structures in tables, but it is incredibly flexible and powerful AND even easier once one has switched the thinking over to it.
I did application development in tables with SQL myself for a few years and I experienced that paradigm shift confusion myself. During the transition, there were constantly moments where I thought "Can I just do that...? Yes!" and "Is it really that simple when purely working with a graph...? Yes, it is!".
This would be it, except there's one more point.
Actually, #1 is not entirely true.
True is: There is exactely one dedicated root object for the whole graph / the whole database.
However, constants in Java classes have to be resolved correctly to avoid inconsistencies during loading. Usually, such constants are just value type instances or otherwise stateless or immutable. Like in JDK BigDecimal.TEN or Collections.emptyList(). However, no one prevents anyone from writing a constant with mutable content, say a reference into the persistent object graph. On a technical level, this would be no different than the dedicated root object and all of a sudden, a single object graph / dataase would have any number of root objects.
We strongly recommend NOT to do that since it can quickly explode into design confusion and inconsistencies. The way described in #3 is much cleaner and less error-prone.