> Avi also suggests the second, but it's not clearly stated as a
> fundamental problem: persistence by reachability. This specifically
> means that they are very Pythonic: there's only *ONE* way to get at
> a particular set of data. In a traditional RDBMS, you can access
> data from many directions. Consider the typical example of "owned"
> data, an order and its itemised details (e.g., the items on the
> order). In an OODBMS, the only way to determine how many Widgets you
> sold last month is to either (1) traverse the object graph for all
> orders last month and visit the order details or (2) store the data
> in both details and elsewhere, doubling your data storage for that
> information. In an (O)RDBMS, you can simply query the order details
> table without having to visit the orders themselves. This makes your
> data much more accessible, and usable for ways that may not have
> been envisioned by the original architects or designers. An OODBMS
> locks you into a particular object model to access the data, leading
> directly to the third problem.

I think there is a need to clarify (at least for me, since I'm dumb and 
I generally don't understand things).
There is one kind of things going under the name of OODB wich seem to 
meet your description, but there is another one, the one advocated from 
ODMG wich seem to collide.
For example, the Object Query Language seem to allow the same kind of 
access to objects that you could get via SQL.

Also I'm not sure I understand: once you have access to the root object, 
if you want to have different views of the data could'nt you just create 
an object wich actually is this view ?