One possible method is the one used by ace-db, to have a model file which explains the class layout and linking. In Java you could use reflection as to the general layout, but not for typing of the collections. Typing could be done by subclassing the collection classes - ugly. Maybe one could use a parametrized collection class, which takes another class as a mandatory construction parameter and assures that every object stored there is of that type. Another possibility is to write the type directly to the flatfile, as an atribute under XML for example.
POET also allows, for queries, to type collections in the configurations file.
The store has a Clerk which will open and close the store, put records on shelf, find them, delete them, low level work for which one has not to have knowledge of the linking or record structure. It also has a Manager, who knows what to do to add and link, delete and unlink, update and relink a set of records or merge a record into another one. Since adding and updating means that you have to translate an external representation, as well as know what is in store, he can read and boss the clerk around to do work. A Flatfile administers a collection of Record s, which in turn are used in the StoreManager to update the database. It serves as a adapter around an hashtable and provides typesafe access to the Records as well as utility functions to parse them from a file and print them out.