Following are the key entities from the ALM Data Warehouse database model. Use these high-level entities as a starting point for reporting against the larger model.
The REP_SOURCE table contains a list of sources that populate the ALM Data Warehouse database. The SOURCE_ID primary key is used throughout the system to ensure that records from multiple systems are not combined. Always include the SOURCE_ID when querying the database, even when returning data from multiple sources. Tables not marked with a declarative foreign key directly related to the REP_SOURCE table are marked with the SOURCE_ID back to the immediate parent as part of the primary key. Each table includes the SOURCE_ID as part of the primary key.
Note: TestTrack was renamed Helix ALM in the 2017.1 release. The Helix ALM database schema uses the following names for item types: defects, requirements, requirement documents, test cases, and test runs. Keep in mind that your organization may have renamed these items in Helix ALM. The default terminology for ‘defect’ changed to ‘issue’ in TestTrack 2012.0, but the database schema uses ‘defect’ to maintain backward compatibility.
Helix ALM data is available starting with two key tables: TT_PROJECT and TT_EVENT. These tables have globally-defined values for all Helix ALM products.
The TT_PROJECT table lists properties of the Helix ALM projects defined in the ALM Data Warehouse database. The PROJECT_ID primary key is used throughout the Helix ALM tables with the SOURCE_ID to ensure that records from multiple projects are not combined. Always include the PROJECT_ID when querying the Helix ALM portion of the database, even when returning data from multiple projects. Tables not marked with a declarative foreign key directly related to the TT_PROJECT table are marked with the PROJECT_ID back to the immediate parent as part of the primary key. Each Helix ALM table includes the PROJECT_ID as part of the primary key.
Helix ALM has five item types: defects, requirements, requirement documents, test cases, and test runs. Each item type has workflow events that are associated with the main artifact table (TT_EVENT). Event definitions are derived from the TT_EVENT table. Each row represents one event definition and can have multiple fields. Key fields in this table include event type and event definition. The primary key for the EVENT_ID table is used in the item-specific event tables and events can be tracked through Helix ALM.
Each Helix ALM defect is stored as a row in the TT_DEFECT table. Use this table as a starting point for reporting on defects and navigate to subordinate tables for additional data.
Workflow events related to Helix ALM defects are stored in the TT_DEFECT_EVENT table. Default and custom events are stored in this table with relationships to the TT_USER table, TT_STATE table, and a self-reference for events with predecessors. Use this table as a starting point for reconstructing or tracking defect events.
Each Helix ALM requirement document is stored as a row in the TT_DOCUMENT table. Use this table as a starting point for reporting on requirement documents and navigating to the TT_DOCUMENT_SNAPSHOT, TT_FOLDER_DOCUMENT, and other subordinate tables for additional data.
Workflow events related to a Helix ALM requirement
document are
stored in the TT_DOCUMENT_EVENT table. Default and custom events are
stored in this table with relationships to the TT_USER table and a
self-reference for events with predecessors. Use this table as a
starting point for reconstructing or tracking requirement document
events.
Each Helix ALM requirement is stored as a row in the TT_REQUIREMENT table. Use this table as a starting point for reporting on requirements and navigating to subordinate tables for additional data.
Workflow events related to a Helix ALM requirement are stored in the TT_REQUIREMENT_EVENT table. Default and custom events are stored in this table with relationships to the TT_USER table, TT_REQUIREMENT table, and a self-reference for events with predecessors. Use this table as a starting point for reconstructing or tracking requirement events.
Each Helix ALM test case is stored as a row in the TT_TESTCASE table. Use this table as a starting point for reporting on test cases and navigating to the TT_ASSIGNED_TESTCASE_USER, TT_NOTIFY_TESTCASE_USER, and other subordinate tables for additional data.
Workflow events related to a test case are stored in the TT_TESTCASE_EVENT table. Use this table as a starting point for reconstructing or tracking test case events. Default and custom events are stored in this table with relationships to the TT_USER table, TT_TESTCASE table, and a self-reference for events with predecessors.
Each Helix ALM test run is stored as a row in the TT_TESTRUN table. Use this table as a starting point for reporting on test cases and navigating to the TT_ASSIGNED_TESTRUN_USER, TT_NOTIFY_TESTRUN_USER, and other subordinate tables for additional data.
Workflow events related to a Helix ALM test run are stored in the TT_TESTRUN_EVENT table. Use this table as a starting point for reconstructing or tracking test run events. Default and custom events are stored in this table with relationships to the TT_USER table, TT_TESTRUN table, and a self-reference for test run events with predecessors.
Helix ALM License Server data is available starting with two key tables: LS_EVENT and LS_USER.
The LS_EVENT table lists events with date and time components. The unique event identifier, date and time the event occurred, and logged event type are recorded in this table. You can navigate to the LS_EVENT_USER, LS_EVENT_DETAIL, and other subordinate tables from this table.
The LS_USER table contains data about all users in the ALM Data Warehouse database. This table links to user email and phone details, events the user participated in, and licenses assigned to the user. Relationships in this table trace back to event details, license pools, and products.
QA Wizard Pro playback data is available in the QAW_PLAYBACK_SESSION table, which links to descriptive information in other tables.
The QAW_PLAYBACK_SESSION table lists playback events
with start
time, end time, and user information. The playback data also lists
container information and filenames, run status, host names, if the
session was remote, and if the user was authenticated through the Helix
ALM License Server.
The playback session data follows one of two paths: either the session
was the result of a script running or the result of a load test.
Detailed load test data is available in the QAW_LOAD_TEST table.
Detailed script run data is available in other QA Wizard Pro tables.
Surround SCM is event driven. Use the SCM_EVENT table as a starting point for reporting on branches, repositories, files, and other data.
| |