1). Table NJAMS_T_MONTOR_MAIN holds meta-data about each process instance, such as its start and end time.
2). Table NJAMS_T_MONITOR_TRACKS holds meta-data about each sub-process that was executed by the top-level BusinessWorks process instance, such as its name, etc.
3). Table NJAMS_T_TRACK_TEMPLATES holds the actual execution path for each sub-process, such as which activities have been executed in which sequence, etc.
4). Table NJAMS_T_MONITOR_BO holds data about Business objects which is seen in Business view. If you have configured extracts/aspect configuration or you are using BWPM client pallets in your application and if you have set Business objects, then data will be added in NJAMS_T_MONITOR_BO . 
5). Table NJAMS_T_MONITOR_BS  holds data about Business services which is seen in Business view. If you have configured extracts/aspect configuration or you are using BWPM client pallets in your application and if you have set Business services, then data will be added in table NJAMS_T_MONITOR_BS . 
6). Table NJAMS_T_MONITOR_ATTRIBUTES holds data about Custom Attributes. If you have configured extracts/aspect configuration or you are using BWPM client pallets in your application and if you have set custom attributes, then data will be added in a table NJAMS_T_MONITOR_ATTRIBUTES.
7). Table NJAMS_T_STATISTICS holds data about Activity Statistics, i.e., data about execution time taken by each activity and it is used to display process trending in the BWPM GUI.
8). Table NJAMS_T_DP_STATISTICS  - This data is used to Show data provider statistics in the BWPM GUI. Also, this data is used to see a graph on a data provider statistics page.

Whenever a new process instance is about to be stored in the BWPM database, the BWPM server checks whether the sub-process and its activity sequence are known by the system. If they are not known, entries are made into the NJAMS_T_TRACK_TEMPLATES table. If they are known, the NJAMS_T_MONITOR_TRACKS table will just reference the corresponding entries in NJAMS_T_TRACK_TEMPLATES, but will not add additional records into the NJAMS_T_TRACK_TEMPLATES table.

Example: Process “A” has these Activities: “Activity 1” and “Activity 2”.

The first time Process “A” executes, one entry is made into the NJAMS_T_TRACK_TEMPLATES table. That entry describes that the processes executed “Activity 1” and then moved on to “Activity 2”. It also holds the execution times (such as how much CPU time was used, etc). The next time Process “A” executes and the sequence of activities and their timings are identical to a previous run, no entry is made in NJAMS_T_TRACK_TEMPLATES. A new entry for that process instance is made in NJAMS_T_MONITOR_TRACKS, which just references the NJAMS_T_TRACK_TEMPLATES entries. If in a subsequent execution of Process “A”, anything in the execution timings of Activity 1 or Activity 2 is different (for example they take a millisecond longer), new entries are made in NJAMS_T_TRACK_TEMPLATES.

What you can see from this is the following:

1). In a best case scenario, all process executions would be 100% identical with regards to their execution though the data processed will be different. In such cases the NJAMS_T_TRACK_TEMPLATES table would only have one entry, no matter how many processes have been executed.

2). In a worst case, all process executions are unique. This means no two processes are identical when it comes to the sequence and execution timings of the activities. In such a case, the table NJAMS_T_TRACK_TEMPLATES will have many records.

3). On average we see that about 5% of processes are unique while 95% share the same execution plan. In this scenario the NJAMS_T_TRACK_TEMPLATES table grows in the beginning, but growth slows down over time as more variations are stored and known and can be reused by the system.
 
Regarding data size in NJAMS_T_TRACK_TEMPLATES table:

· A large NJAMS_T_TRACK_TEMPLATES table not necessarily is a bad thing. It shows that the processes executed have a high degree of uniqueness and that many processes are executed.

· The user can configure a retention period for NJAMS_T_TRACK_TEMPLATES using the UI . The default settings is 14 days. Any entry in NJAMS_T_TRACK_TEMPLATES that is not used, as in referenced by entries in the NJAMS_T_MONITOR_TRACKS table, will be deleted automatically by a purge job every night.

· The size of the table can be controlled by reducing or increasing the retention period for “Tracks” in the BWPM UI.