The root of the relational in . The primary design intent is to make it simple to be built by hand. This means a few things, but the general idea is to keep it itght and normalized, yet still as specific as possible. Keeping it normalized will keep it tractible for consumption, however should consumers require additional indexing, then the idea is to provide them their own model that "decorates" this one with the indexes, e.g. "publishedRelationalMetadata.xsd". It is largely an inferral of the UDA SqlApi functions employed by FM's import process (found in the Documentation Center page go to http://dinobot), but also takes into what account what the JDBC java.sql.DatabaseMetadata API returns which does seem to be similar to UDA's APIs). Note: There are a lot of attributes here, if viewing in XMLSpy 2008 Schema Design view you may want to select the "Display attributes in toolbar" button. The release version of the product against which this model was built. Note that the reference object may reside in different catalog / schema. references to columns only within the same table / view Note that the reference object may reside in different catalog / schema. intended to be specified only if its a reference to a separate schema intended to be specified only if its a reference to a separate schema The name of the (primary key) table whose columns are being imported Also often referred to as "collation sequence". Default is "ascending", and yes it is optional here because "ascending" is often the case. The name of a column contained within the same parent table. The order matters here and should logically match that as in the database. The names of the columns contained within the same parent table that comprise this "exported column" list involved in this referential constraint. The name of the unique key contained within the imported table, whose columns will comprise imported columns list). This is designed rather generically because vendor implementations vary greatly. The names of the columns contained within the table (above) that comprise the columns list for this index. Also often referred to as "collation sequence". Default is "ascending", and yes it is optional here because "ascending" is often the case. Specifically, is the composition values unique for every "columnRefList" record. Like "indexType" in JDBC RESERVED FOR FUTURE USE: Fallback case in case for some vendor the concept of a imported key did not pertain to the foreign key, and all we got back was a list of primary key column references. I'm not even sure if this is possible for our conformance, but for some reason UDA kept the primary key optional in their APIs, and so this is here to accomodate for such a case/ The names of the columns contained within the same parent table that comprise this "exported column" list involved in this referential constraint. The names of the columns contained within the same parent table that comprise this "exported column" list involved in this referential constraint. TO DO: Accommodate for DB2 nickanmes? The name of the targe table, view, routine or index. An stored procedure or a user-defined function (UDF). It is structured generically because we are really talking about an executable body of code here. The only real difference between a procedure or a UDF is that a UDF can be directly invoked in sql, whereas a procedure must be invoked via a CALL stattement in a calling block of stored code - this is captured in the "invocationType" attribute. What kind of results they can or cannot (scalar, result set, none) what kind of parameters they can take in (see the "mode" attribute) varies amongst vendor implementations, especially considering that some don't even return all this information. An stored procedure or a user-defined function (UDF). It is structured generically because we are really talking about an executable body of code here. The only real difference between a procedure or a UDF is that a UDF can be directly invoked in sql, whereas a procedure must be invoked via a CALL stattement in a calling block of stored code - this is captured in the "invocationType" attribute. What kind of results they can or cannot (scalar, result set, none) what kind of parameters they can take in (see the "mode" attribute) varies amongst vendor implementations, especially considering that some don't even return all this information. This option serves as a fallback for a strange case wherein the database provider does not return a "target", which is the case for the JDBC DatabaseMetadata API interface!!!!. They still return the synonym (in their "getTables" request), just not the target. But they also may return the columns of the target table (although not the target). This loss of target and could potentially represent a problem for consumers. So, this option is here as a fallback. Hopefully, this hole can be restricted to ODBC sources. Need to investigate what UDA is doing, and devise a strategy to accomodate for this. Specified only if the object is "contained" in a separate schema. The order of subroutineArguments must match that as in the actual signature in the database.