There is not documentation about the data model.  HOWEVER, what I've done in the past is to pull down the out-of-box reports you get, and extract those files.  You will see a xml report defintion file that includes the query used in the report.  This is a really good way to get an idea abotu how tables join together, and common filters/where clause you need to include (to avoid deleted, not current records, for instance).   

Another really good learning tool is the insight query. If you can build something similar to what you want to query for, you can save that as a query, and then run over to the metrics configuration -- add a new metric based off your query, and BOOM, it shows you the SQL to generate it.    These two tricks are great.   

Lastly, if you happen to be on MS SQL (deprecated soon!)  you can use the database diagram tool, and just drag and drop tables in, and it will autogenerate a diagram with references and foreign keys for you.  That is less useful, but better than nothing, especially if you like diagrams.

--Jim

Hello,

   In addition, make sure your custom reports only utilize the existing Views and do not go against the existing Tables.  The Best Practice is to only utilize the Views and the user igrptuser.


Sincerely,
Steven Williams
Principal Enterprise Architect
OpenText Cybersecurity

What do you mean by existing Views? I did not really get the point. Can you provide me with more details?

Reports sometimes come delivered with a view that is added to the database that supports the underlying query.   Then in the report definition, it just does a select from the view, and you can't see the query table joins.   In that case you can go into the database engine and have it describe or define the view for you.

Hello,

   When you look at the IGOPS database there are Tables and Views.  All Reports look at views (which get their data from Tables).

Sincerely,
Steven Williams
Principal Enterprise Architect
OpenText Cybersecurity

Okay Now I see. Thanks all for your help