Cleaning the linking structure

[martinjuckes]

We have links to variables via requestVarGroup records, to MIPs via objectives and to experiments via requestItems and either experimentGroups or MIPs acting as implied experiment groups. Introduce “bridging tables” to provide many-to-many mappings. Some tables are close to this function, but share the same core metadata attributes as other tables.

• Define many-to-many links from requestLink records to:
  (1) requestVarGroup (currently one requestVarGroup to many requestLinks);
  (2) requestItem or revised experimentGroup
  (3) objective;

The requestItem currently links to either an experimentGroup, experiment or MIP (acting as an implicit experiment group). The requestItem carries time slice information and other "request" information: treset, preset, nenmax. Pushing all this information onto the experimentGroup would result in a proliferation of groups with the same set of experiments. Hence, the initial preference is to keep these in requestItem.

Bridging tables will be added to handle the many-to-many relationships. For the section tables, each record has a uid, label and title plus additional attributes which vary from section to section. The bridging tables will have have a common structure: each record will have just two links: "a" and "b", which will link to records in two specified tables. The table will carry methods to:
(1) list links all specified in "a" or "b" -- table.keys( 'a' );
(2) list links in "b" associated with a specific link in "a" and vice versa -- table.targets( a="xxxxxx" );