The vector dependency tree representation below is induced by (manually) eliding edges from the foreign key dependency graph for the dbms relations, according to four cases:

- Edges that lead to multi-node cycles are removed by eliminating the
offending foreign key type specification in the schema table returned
by TupK:schema(). For now, this is a problem only with ComboSet and
ComboLeg. It follows that these tables are not yet effectively
supported, and that they will need to be redesigned before becoming
useful.
- Self edges are removed; it is up to the downstream user to ensure
that local keys in tuples are strictly less than the tuple id.
- Edges to functional tables are removed; these tables are checked
exactly once, prior to any vector input, and so are well defined
as long as downstream users do not (incorrectly) alter such tables
while the shim is running.
- Redundant edges are non-deterministically removed from the resulting
acyclic graph until the result is a free tree.

The third step is not only a significant optimization, as it reduces dbms load, but also necessary for correctness, since the table provided for vector lookup during the post-order traversal does not include the functional tables, so that there would be an index-out-of-range error if edges for those tables were included.

The last step, though at most a minor optimization, is actually more a matter of convenience, as fewer edges need to be added to the adjacency lists below.

Note that the initial - and resulting - dependency graph *includes* the union-join edges for the variant parts of Contract (e.g., FutDetail) and SubRequest (e.g., PastFilter), even though these foreign key dependencies are not explicitly declared via the sql create table statements.

See the foreign.* files in ../dot for a graphical representation of the dbms foreign key dependency graph. Union-join (tagged variant key) edges are indicated there by dashed-line edges.

Bill Pippin 2010-01-14