What database structure for a document management system?

Question

I want to store a document and then decide what workflow to apply to the document. That workflow will request users to perform actions on the document, and capture the actual actions performed. eg

DocId=2    
Flow = 1.[Mr.X - Authenticate]   2.[Mr.Y - Verify/Reject]  3.[Mr.Z Accept/Reject]  

What database architecture will support these tasks?

Answer 1

The schema for workflows is greatly affected by whether your workflows have branching or not. If all of your workflows are linear with no branching, the problem is much simpler, because the definition of a workflow configuration need only list the steps in the workflow, and a document workflow instance only needs to record the current step. If conditional branching or parallel steps are involved, you need to use some sort of hierarchical model for the steps (eg each workflow configuration step could have a pointer to parents and pointer to children). These are often stored in XML.

The simple case with no branching can look like this:

table: workflow_config (one row per workflow)

• workflow_config_id
• name
• description

table: workflow_config_step (one row for each workflow step)

• workflow_config_id
• step_id
• name
• description
• action_id
• parameters (or context, or whatever information needs to be passed to the action launcher)

table: document_workflow (one row for each document)

• document_id
• workflow_id
• current_step_id
• parameters (or context, or whatever information needs to be passed from one step to the next)

table: document_workflow_step (one row for each action taken on the document)

• document_id
• step_id
• status
• timestamp

Note that branching workflows need to carry much more information from stage to stage. In fact the "parameters" attribute may need to be in a separate crosslinked table. I'm only calling it a field here because you may use delimited or XML representation if very little data is needed.

Answer 2

The following is the skeleton of a potential architecture to support your application. It contains definitions of the tables, and columns in the tables, together with some example data for each table. Permitted transactions has two purposes: to generate the requested actions for a particular document in a particular state; and to validate actions when they are appllied to the database.

State
  Value (PK)

  Example Data
    Initial
    Authenticated
    Verified
    Rejected
    Accepted

Flow
  Flow ID (PK)
  Description

  Example Data
    27,Authenticate and validate general document

Permitted Transition
  Current State (PK)(FK)
  Action Type (PK)(FK)
  Result State (PK)(FK)
  Flow ID (FK)

  Example Data
    Initial,Authenticate,Authenticated

Action Requested
  User (PK)(FK)
  Document (PK)(FK)
  Action Type (PK)(FK)

  Example Data
    Mr.X,2,Authenticate

Document
  Document ID
  Current State (FK)

  Example Data 
    2,Initial

Document Flow
  Document (FK)
  Flow (FK)

  Example Date
    2,27

User
  Name

  Example Data
    Mr.X
    Mr.Y
    Mr.Z

Action Type
  Value (PK)

  Example Data
    Authenticate
    Verify
    Reject
    Accept

Action
  Action Type (PK)(FK)
  User (PK)(FK)
  Document (PK)(FK) 

  Example Data
    Authenticate,Mr.X,2