[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Federated DataBase with Multiple Component Events




Jie and I have setup a federation with hijing events with boot file
/common/GC/dbases/fd30007/hij.fdboot. 
The federation has 57 data base files each of which has 20-30 hijing
events.  The total number of events in the federation is 14325.

There are two navigation databases in the federation: the TagDataBase and
a HeaderDataBase.  

The HeaderDataBase contains one object for each event.  That object
contains a reference to the tag for that event and a reference to the
event body (oParticles object) for that event.  

The tag data base has a similar schema to previous hijing federations
with some additional data members:
  d_Short _fid;         // file identifier for the oParticles object
		        //   corresponding to this event
  d_Short _fidcomp1;    // file identifier of file for component1
  d_Short _fidcomp2;    // file identifier of file for component2
  d_Short _fidcomp3;    // file identifier of file for component3
  d_Short _fidcomp4;    // file identifier of file for component4

  d_Float _TagRand;     // random number from 0-2000.

the file identifiers are objectivity database ID's for files which are
associated with this event.

The databases which are selected as component's for a given event are
selected at random from the other databases in the federation.  The only
condition being that a component dbase for a particular event will not 
be the HeaderDataBase, TagDataBase, the database with the oParticles
object for this event or a database which has already been selected as one
of the other file components already.

Note that these conditions do not mimic the realistic situation
in as much as the following circumstances are often true.  That is, the
database with component1 for event i is the same as the database with
component3 for event j.

		event 1		event2		event3
		fileIDs 	fileIDs	  	fileIDs
		*******		*******		*******
header		21		21		21
tag		22		22		22
event body	23		55		78
component1	55		78		92
component2	113		67		23
component3	14		24		101
component4	101		99		3

But they may be sufficient for multi-component event retrieval testing.