Question

I’m working on a database design for a Java web application work flow app to track and check various business products (documents). But I have a number of uncertainties with its design and implementation.
Here are my tables:

• WORK_FLOW_CLASS – definitions table of work flows for types of products, i.e.: Reports, Presentations, Engineering Calculations

• ROLE_CLASS – definition table of work flow roles, i.e.: Originator, Checker, Approver, Manager

• WORK_ITEM_CLASS – definition table of work items that represent some paper form, i.e.: Assignment Form, Calculation Checklist, Report Review Form, Closeout Checklist, etc. These forms require to be worked by multiple roles in a certain order before being considered complete

• WORK_ACTION_CLASS – definition of work item actions, i.e.: complete Calculation Checklist (a WORK_ITEM) by Checker (a ROLE), complete Review Report (a WORK_ITEM) by Manager (a ROLE), complete Review Report (a WORK_ITEM) by Approver (a ROLE)

• WORK_FLOW_SEQUENCE – definition table relating a WORK_FLOW_CLASS to the MANY WORK_ITEM_CLASSes, i.e. Department ABC Level 1 Calculation sequence is: (1) Assignment Form, (2) Calculation Checklist, (3) Closeout Checklist. Department XYZ Level 1 Calculation sequence is: (1) Assignment Form, (2) Closeout Checklist [XYZ chose to not do the checklist in their Calc work flow].

First question: Should the WORK_ACTION_CLASS have a FK to relate it to the WORK_ITEM_CLASS?

Or should I use an Intermediate table to provide the relationship? I think the latter would be unnecessary because I wouldn’t need to relate a WORK_ACTION to multiple WORK_ITEMS, only one.

When a user starts a new Work Flow Instance my plan is to query the CLASS tables for the details of the selected WORK_FLOW_CLASS and instantiate them into the following tables.

• WORK_FLOW_INSTANCE – Actual Instance of a work flow – I guess like a Shopping Cart Order

• WFI_WORK_ITEMS – Work Flow Instance line items of WORK_ITEMs – I guess like the products in an Order

• WFI_WORK_ITEM_ACTIONS – Work Flow Instance Work Item Actions

Here is where I need help with the second question.

Should there be the two separate tables WFI_WORK_ITEMS and WFI_WORK_ITEM_ACTIONS or should I have one compound table? I will need to query just the WORK_ITEMS in the work flow instance as well as the WORK_ITEMS with the sub step WORK_ACTIONS.

here is the details for the two tables in questioned. Sorry I do not know the best way to depict my schema.

WFI_WORK_ITEMS
==============
WFI_WORK_ITEM_ID (PK) 
WORKFLOW_INSTANCE_ID (FK) 
WORK_ITEM_CLASS_ID (FK)
STEP_NUM
LAST_DATE
STATUS
IS_ACTIVE


WFI_WORK_ITEM_ACTION
====================
WFI_WORK_ITEM_ACTION_ID (PK) 
WORKFLOW_INSTANCE_ID (FK)
WFI_WORK_ITEM_ID (FK) 
WORK_ITEM_CLASS_ID (FK)
STEP_NUM
WORK_ACTION_CLASS_ID (FK)
ACTION_OWNER
LAST_DATE DATE
STATUS
IS_ACTIVE

I seem to have a lot of redundant info in these two tables. But I have read sometimes de-normalizing tables is performed.

Any help with my design is greatly appreciated.

EDIT
What I meant by redundant data is that both tables list the WORKFLOW_INSTANCE_ID and WORK_ITEM_CLASS_ID My thought was if I wanted to know the WORK_ITEM_ACTIONS for a particular instance of a WORKFLOW, I could get it by querying the table WFI_WORK_ITEM_ACTION without joining the ‘WFI_WORK_ITEM’ table. Maybe this is wrong thinking. The same for WORK_ITEM_CLASS_ID. By querying the WFI_WORK_ITEM_ACTION table, I’d know the type of WORK_ITEM the ACTION was for.

Is this a better design?

WFI_WORK_ITEM
==============
WFI_WORK_ITEM_ID (PK) 
WORKFLOW_INSTANCE_ID (FK) 
WORK_ITEM_CLASS_ID (FK)
WORK_ITEM_STEP_NUM
WORK_ITEM_LAST_DATE
WORK_ITEM_STATUS
WORK_ITEM_IS_ACTIVE


WFI_WORK_ITEM_ACTION
====================
WFI_WORK_ITEM_ACTION_ID (PK) 
WORKFLOW_INSTANCE_ID (FK)
WFI_WORK_ITEM_ID (FK) 
WORK_ITEM_CLASS_ID (FK)
WORK_ACTION_STEP_NUM
WORK_ACTION_CLASS_ID (FK)
ACTION_OWNER
WORK_ACTION_LAST_DATE
WORK_ACTION_STATUS
WORK_ACTION_IS_ACTIVE

Answer 1

You should always start by designing your tables in third normal form (3NF). It’s quite acceptable to revert to lesser forms (for performance reasons usually) provided you understand and mitigate the impact, but start with 3NF.

The (slightly simplified) rule to remember is that every non-key column in a table should depend on:

• the key,
• the whole key,
• and nothing but the key,
• “so help me, Codd” – a little DBA humour (and I do mean “little”).

The first question is fairly simple.

One-to-many relationships are best represented as a foreign key in the “many” table. So what you propose is sensible. It allows you to restrict the relationship automatically. If you had a separate joining table (used for many-to-many), you would need to resort to “trickery” to enforce the one-to-many relationship.

As to your second question, you need to look to the “Codd” rule above and think to yourself: what exactly are these rows in each table representing? If a work item action is a distinct object from a work item (they may be related but, if they’re not representing the same object, they’re distinct), they should be in different tables.

In addition, it appears you have a one-to-many relationship there (one item can have many actions) so they should be in different tables for that reason alone.

As to your query on the redundant info: if they really are redundant, they should be repaired.

Using the step_num as an example, what exactly does this represent? If it’s an attribute of the work item, it shouldn’t be in the work action table at all.

You would get rid of it from there and, if you wanted to know the step number for a row in the work action table, you would join with the work item table using the foreign key.

If instead it’s an attribute of the work action, you should remove it from the work item table since it makes no sense. You might have two actions each with a different step number so what would the step number of the parent item be in that case?

Of course, you may have a distinct step number for both items and actions – in that case, I would consider renaming to make the intent clear, something like item_step_num and action_step_num.

Bottom line is to start with 3NF. If at some point your database runs too slow, then consider reversion to a lesser form. You can then ask another question here about how to recognise and mitigate the problems that arise from that (for example, the possibility of inconsistent data in two places, and using triggers to prevent that).