Integrating > Integrating with IBM Cognos > The ODS database
  
The ODS database
The ODS database is created by SA Schema Generator and data is populated by the SA Data Retriever with encyclopedia data. The ODS table contains relationships between encyclopedia metamodel objects on which you can report. At the highest level, the encyclopedia metamodel describes three basic “major types”: diagrams, symbols, and definitions, and within each, many “minor types”. For example, a diagram of type BPMN Process is a “minor type”. Diagram “minor types” and symbol “minor types”.
Information about the tables in the ODS database includes the following items:
For each minor type in System Architect, a separate table is created in the ODS database.
The ODS database table names are prefixed with:
Def_ for Definition minor type
Dia_ for Diagram minor type
Sym_ for symbol minor type
It is possible in System Architect to have same “minor type” name but with different “minor type” number, and if the symbol is assigned to a diagram “minor type” then the table name will be in the form:
Sym_<minor type>(Diagram minor type)
For example: The “Physical Package” symbol is assigned to both “Structure chart” and “System/Subsystem Structure” diagrams. Therefore, in ODS the table names for these symbols are “Sym_Physical Package (Structure Chart)” and “Sym_Physical Package (System/Subsystem Structure)”.
Each symbol and diagram has a “Relation” table of its own where all the symbol and diagram relationships will be dumped. The relationship information dumped into the tables is picked up by the contents of SARelationFile.xml file.
For example: The “Physical Package” symbol has the form Sym_Physical Package (Structure Chart)_Relation in ODS, where all the relationship information of the symbol “Physical Package” will be dumped. By default, SARelationFile.xml contains some default relationship for diagram and symbol. The default relationships are provided below.
Type
Relationship
Description
Diagrams
Expands from
For getting the Parent symbol
 
links to
For getting the list of definition linked to this diagram
Symbol
links to
For getting the list of definition linked to this symbol
 
Connects
For getting the list of symbols which it is connected to/from
 
Embeds
For getting the list of symbol it embeds
 
Expands to
For getting the child diagram under the symbol
 
Is embedded by
For getting the symbol in which the current symbol embeds
The diagram relations are populated into a Dia_<diagram minor type>_Relation table and symbol relations are populated into a ym_<symbol minor type>_Relation table.
A separate table is created for a workspace, which is stored in a table named “Workspace” in the ODS database.
The ODS database creates look up tables for every referenced property which is “not keyed” by, to relate two definitions. Each lookup table name in the ODS database is prefixed with LK_ and if the lookup table is created for definition it will be followed by Def_. The table naming convention is:
LK_Def_<Definition minor type>_<property name>
For example: The definition minor type named “Peripheral” has a property 'Brand' which is a referenced property of the referenced definition “Vendor.” Therefore, a look up table is created with the name “LK_Def_Peripheral_Brand”.
DEFINITION "Peripheral"
{ PROPERTY "Brand" {EDIT LISTOF "Vendor"} }
The above lookup table needs to be used when you want see the list of vendors corresponding to a given peripheral definition. If you are interested in just viewing the list of vendor names and not the properties, then you can use the Brand column in the Def_Peripheral definition. If you are interested in some of the properties of vendor definition then, then you can use the above lookup table for it. If a lookup table is created for symbols, which has the same minor type name but different minor type numbers, the look up table naming convention is:
LK_Sym_<Symbol minor type name(<Diagram minor type>)_<property name>
If a symbol “minor type” is assigned to a diagram type, a foreign key relationship is created between the two tables.
For example: “Class” symbol is assigned to Class diagram, therefore, a foreign key relationship is created between the Sym_Class and Dia_Class tables.
If a symbol “minor type” is defined by a definition type, then a foreign key relationship is created between the two tables.
For example: “Process” symbol is defined by “BPMN Process”, therefore, a foreign key relationship is created between the Sym_Class and Def_BPMN Process tables.
The ODS database does not create “look up” tables for every referenced property which is a key property.
For example, in the code snippet below, Class is keyed by Package through the property Package. In this case, a lookup table is not created for this property.
DEFINITION "Port"
{
PROPERTY "Package"{KEY EDIT OneOf "Package" READONLY}
}
In the above case, the look up table is not created for the Package property, but a foreign key relationship is created between Def_Port and Def_Package, having Package Identity and a Package workspace ID.
The ODS database is populated by an IBM Cognos administrator who runs the SA Data Retriever manually, or as a scheduled task, to get data from the System Architect encyclopedia. (The ODS database gets populated thorough the REST Service.) In turn, IBM Cognos queries the ODS database that is populated with encyclopedia data.
See also
Generating the ODS schema
Retrieving encyclopedia data
Publishing packages with Framework Manager
Generating reports from System Architect
Built-in troubleshooting and testability
Integrating with IBM Cognos