K2数据库database

When looking at the K2Log database, the hierarchy is as follows: 

 

_ProcInst 

This is one of the highest level tables, which contains a unique row (with unique ID) for each 

process instance. The ‘ID’ column is the unique Process Instance ID, and the ‘ProcID’ column is a foreign key reference to the 

_Proc

 table which contains the process definition (name, descr, etc). 

Therefore a list of ‘incidents’ can be obtained by creating a query from the _ProcInst table. 

 

_ProcInstData 

All the instance data for a process, is stored in ProcInstData. Each row in PRocInstData has a 

foreign key reference back to the ProcInstID (which is stored in _ProcInst.ID). 

 

_ActInst 

This is the next level. For each process instance, all activity instances are stored in _ActInst. This 

table contains a foreign key to table _Act in order to link the name & description for the activity. 

From this table we can obtain the overall status for the activity, however because an activity can 

be sent to a single or multiple users, no user-related information is found here, but rather 

extrapolated to _ActInstDest. 

 

_ActInstDest 

This table contains a unique row, for each ‘destination’ for a particular activity instance. There, if 

we sent Activity ‘Approval’ to ‘UserA, UserB and UserC’, there will be a si

ngle row in _ActInst for 

the overall activity, and 3 rows in _ActInstDest, one for each user. Therefore, as can be expected, 

this table is important for any user-related queries (such as particular tasks for a specific user etc).  

 

_ActInstDestData 

Activity data is created as a separate set of data for each destination user. Therefore, the data 

fields are stored relative to a specific ActivityInstanceDestination. This table contains a row for 

each data field, for each destination user. Therefore, if you create 2 data fields (Field1, Field2) for 

the activity mentioned above, then you will have 6 rows in _ActInstDestData. 

 

_EventInst 

This is the lowest table. Each row has a foreign key back to _ActInstDest. Each row in this table 

is for a single event, for a single user. 

 

Many of these tables, contain the start and finish date (for the specific level, be it process,activity, 

or event), as well as the current status. Therefore, for most queries a combination of these tables 

must be used.  

 

So for instance, the following would give you an idea on where to obtain the indicated information: 

 

- number of tasks for a user or a group of user

(this can be read from _ActInstDest, that is where we know which activities were sent to which 

user) 

 

- number of Activities  

To get the activities per user, _ActInstDest has this info. 

 

- number of process instances 

This can be obtained from _ProcInst. 

 

- type of Activity steps 

If a step is an activity, then you would use the Activities’ name/description to uniquely identify it, 

and inner join _Act and _ActInst to get the name and description for a specific Activity Instance. 

 

- status of steps

When looking at the K2Log database, the hierarchy is as follows:

 

_ProcInst

This is one of the highest level tables, which contains a uniquerow (with unique ID) for each process instance. The ‘ID’ column is the uniqueProcess Instance ID, and the ‘ProcID’ column is a foreign key reference to the _Proctable which contains the process definition (name, descr, etc). Therefore alist of ‘incidents’ can be obtained by creating a query from the_ProcInsttable.

 

_ProcInstData

All the instance data for a process, is stored in ProcInstData.Each row in PRocInstData has a foreign key reference back to the ProcInstID(which is stored in _ProcInst.ID).

 

_ActInst

This is the next level. For each process instance, all activityinstances are stored in _ActInst. This table contains a foreign key to table_Act in order to link the name & description for the activity. From thistable we can obtain the overall status for the activity, however because anactivity can be sent to a single or multiple users, no user-related informationis found here, but rather extrapolated to _ActInstDest.

 

_ActInstDest

This table contains a unique row, for each ‘destination’ for aparticular activity instance. There, if we sent Activity ‘Approval’ to ‘UserA,UserB and UserC’, there will be a single row in _ActInst for the overallactivity, and 3 rows in _ActInstDest, one for each user. Therefore, as can beexpected, this table is important for any user-related queries (such asparticular tasks for a specific user etc).

 

_ActInstDestData

Activity data is created as a separate set of data for eachdestination user. Therefore, the data fields are stored relative to a specificActivityInstanceDestination. This table contains a row for each data field, foreach destination user. Therefore, if you create 2 data fields (Field1, Field2)for the activity mentioned above, then you will have 6 rows in_ActInstDestData.

 

_EventInst

This is the lowest table. Each row has a foreign key back to_ActInstDest. Each row in this table is for a single event, for a single user.

 

Many of these tables, contain the start and finish date (for thespecific level, be it process,activity, or event), as well as the currentstatus. Therefore, for most queries a combination of these tables must be used.

 

So for instance, the following would give you an idea on where toobtain the indicated information:

 

-number of tasks for a user or a group of user

(thiscan be read from _ActInstDest, that is where we know which activities were sentto which user)

 

-number of Activities

Toget the activities per user, _ActInstDest has this info.

 

-number of process instances

Thiscan be obtained from _ProcInst.

 

-type of Activity steps

Ifa step is an activity, then you would use the Activities’ name/description touniquely identify it, and inner join _Act and _ActInst to get the name anddescription for a specific Activity Instance.

 

-status of steps

Table_ActInst has a status for the overall activity, _ActInstDest has a status foreach participating user in the activity.

 

-time of steps

Tables_ProcInst, _ActInst, _ActInstDest and _EventInst all have start and finishdates/times. Basically it depends on what level you need the time on.

 

-type of Process instance

The_ProcInst can be inner joined with _Proc to get the name and description.

 

-status of Process instance

_ProcInsthas the status for the overall process.