--############################################################################## -- -- Auth: Paul Brown -- -- $Header: /usr/local/devel/montage/contrib/BigSur/Schema/RCS/bigsur_lineage.msql,v 1.4 1994/12/06 23:37:52 pbrown Exp pbrown $ -- --##################################################################### -- -- These relations are extensions of both FGDC and SAIF, and reflect the -- lessons learnt in the EOS Alternative Architecture study. In that -- project it was determined that, in order to achieve desirable goals -- like Lazy processing and the discovery of data which was the result -- of incorrect algorhythms, the process by which every object was -- created must be stored along with all the information about how -- that process was run. -- -- This can then be combined with other information to determine when -- an object which someone uses in further processing has been created, -- and take the next step automatically. -- -- Some of the features of such a system include; -- -- . The desire to store some (large) set of Process which can be -- used to process data. (All the processes by which data is created -- including 'genesis' processs, which are used when data is added, -- must be stored here.) -- -- . The desire to associate with each process some profile which -- determines the paramaters the process needs to have passed to it -- in order to produce meaningful results. -- -- . The desire to associate miscellaneous information about both the -- Process ( Script, Contact_Id etc) and the Parameters supplied to -- the Process (defaults, types etc) -- -- . The need for flexibility. Some Parameters take a set of -- other data objects as Parameters. This fact, and in each case -- the identity of the data objects supplied to the Process, must -- be stored. -- -- . The need to support ad-hoc queries for both resource discovery -- (I need something that has had foo done to it.) and data -- management (I need to find everything that was the result of foo.) -- -- This schema achieves each of these goals. -- -- Each process may be thought of as having the following prototype; -- -- Result = Process ( Param1, Param2, ... Paramn ); -- -- For each Process, the list of the Parameter { Param1, Param2, ... Paramn } -- passed to the process before it ran must be recorded. -- -- Process = -- processName + -- Some name for the process. -- { Composit, HyperSlab, ... } -- processVersion + -- Version information, because -- there may be multiple versions -- of a process with a certain -- name. Note that the prototype -- employed an elaborate name-space -- mapping. -- Contact_Information +-- Each process was written by someone, -- or someone is responsible for -- maintaining this Process's code. -- -- processScript + -- This is the actual script. -- -- dateAdded + -- Audit information. -- -- (Description); -- Additional comments. -- -- -- -- CREATE TABLE Process OF NEW TYPE Process_t ( processName text NOT NULL, processVersion integer NOT NULL, -- processVersion used because -- Version is a reserved word. Contact_Information ref(Contact_Information_t) NOT NULL, processScript text, dateAdded timestamp default current_timestamp, primary key (processName, processVersion) ) UNDER Description; -- -- Parameters - Extension of both standards for BigSur. -- -- Param Passed to a process. Can't see this in the -- SAIF or FGDC primitives. -- -- Process + -- This is the identify of the -- Process for which this is a -- Parameter. -- deref(Parameter).processName = Composit -- -- paramSeq + -- A list of Parameters must be in -- some order. ( Param1, Param2 . . .) -- This attribute conveys the position -- of this parameter in the list passed -- to the Process. -- 1,2,3 etc. -- -- paramName + -- This is the name of the Parameter. -- { Band_To_Composit, Hyperslab_X, etc} -- -- paramType + -- This is the type of the Parameter. -- { string, integer, timestamp } -- -- paramDefault + -- This is the Parameter's default value. -- -- (Description); -- CREATE TABLE Parameter OF NEW TYPE Parameter_t ( Process ref(Process_t) NOT NULL, paramSeq integer NOT NULL, paramName text , paramType text , paramDefault text, primary key (Process, paramSeq) ) UNDER Description; -- -- This is a little out of place, necessarily so because of the -- interdependencies here. The II table requires that the -- Process table be defined, and the Params table must know about the -- II table in order to know what it has created. -- \i bigsur_section1.msql -- -- Each running of the Process must have the value of each of it's -- Parameter's recorded. This can be thought of as the list of -- Arguements provided to fulfill the Process's Parameter list. -- Note that there is a language problem here. Some people use these -- terms interchangably, and other use the terms in opposite relation -- to the way I have expressed them here. (Process have Arguement -- lists and are supplied with Parameters to evaluate, for example.) -- -- Lineage_Param - Extension of both standards for BigSur. -- -- Stores the actual parameters passed to the process. -- -- Identification_Information -- This is a reference to the -- Identification_Information relation. -- To get the name of the process, you -- would use; -- -- deref(deref(Lineage_Param.Identification_Information).Process).processName -- -- Parameter -- This is a reference to the Parameter -- table. Thus getting the type of the -- arguement stored here would be; -- -- deref(Lineage_Param.Parameter).paramType -- -- argSeq -- This is the sequence number of the -- arguement passed to the Process. -- { 1, 2, 3, ... n } -- -- Note: Param_Seq is necessary here, and cannot be deduced from the -- entry in the Parameters table, because typically the -- Max(Lineage_Param.Param_Seq) = Max(Parameters.Param_Seq) + n, -- where 'n' is the number of objects passed to the process. -- -- These extra arguements must be stored to trace the ancestory -- of a particular object. -- -- argValue -- This is the text value of the -- arguement. As all Illustra types have -- a type_out process, and as DBMS systems -- handle data as string abstractions, there -- should be no type this approach can't -- handle. -- -- Note: In the case that a Parameter required by a Process is a large -- object (and this will be the most common case) then the paramType -- would be 'dlobh' (for example) and the argValue would be the -- dlobh used. This will allow full back-tracking, as the Dlobh is -- a key in another table. -- -- CREATE TABLE Lineage_Param OF NEW TYPE Lineage_Param_t ( Identification_Information ref(Identification_Information_t) NOT NULL, Parameter ref(Parameter_t) NOT NULL, argSeq integer , argValue text ); -- -- -- GRANT ALL ON Process TO PUBLIC; GRANT USAGE ON TYPE Process_t TO PUBLIC; GRANT ALL ON Parameter TO PUBLIC; GRANT USAGE ON TYPE Parameter_t TO PUBLIC; GRANT ALL ON Lineage_Param TO PUBLIC; GRANT USAGE ON TYPE Lineage_Param_t TO PUBLIC; --