Workspaces data model

The following schemas are used in workspaces:

Base schema

Contains the current content.

Write schema

Stores the content changes.

Read schema

Presents how the current and changed content appears.

The data within these schemas is categorized as one of the following types of data:

Content data

Data that is updated by business users.

Operational data

Runtime data associated with the content data.

Configuration data

Data similar to content data but is associated with the store and is not frequently updated.

The base schema contains data that is identical to the production environments. All workspaces draw from this common repository of data but none of their working changes are reflected here. It is in the individual write schemas that any uncommitted changes are stored, thereby isolating workspace 1 from changes in workspace 2. However, when users preview their changes, the write and base schemas are hidden behind the read schema. The read schema first checks the write schema for the requested data and, if it is not found there, then goes to the base schema. Essentially, the read schema consolidates all the altered and unaltered data from the write and base schemas and packages it as a single entity.

Within a workspace context, updates to a resource are directed to the write schema, whereas retrieving data for a resource is directed to the read schema. Each table within the WebSphere Commerce data model is in one of the following classifications that determine the definition of the read and write schema:

Managed content assets

The attribute and its corresponding table are content that needs to be managed in the workspaces model. Content changed in a workspace is stored in a separate data area allocated into each workspace and participates through the actions within the workspace and its task groups and tasks. These assets define each workspace write schema as a physical table to store the data. Content is moved back to the production-ready area when the workspace components life cycle is completed. Extensions to product, marketing and pricing assets are managed content assets.

Managed operational assets

The attribute and its corresponding table represent data created during the operation of the store within preview while in a workspace. This data is specific to the particular workspace and is removed when the workspace component life cycle is completed. Transactional order data is an example of managed operational data in which data can be created in the workspace during preview.

Unmanaged assets (Default)

The attribute and its corresponding table represent content or operational data that is not managed under workspaces. The data is not associated to a workspace and is always referenced from the production-ready data area. By default all other resources that are not explicitly categorized otherwise are treated as unmanaged resources. User and store are examples of unmanaged data.

The following figure illustrates the workspace data model for a content managed resource.

This type of resource has a physical table allocated in the write schema to store changes from within a workspace. A database view of the same name is defined within the read schema that is a union of the write schema table overriding the production-ready schema table. The table within the write schema has nearly the same structure as the production-ready schema with the following exceptions:

• The table has additional columns as follows:

  CONTENT_STATUS - CHARACTER(1)

  The operation performed on this instance of the resource within this workspace. Possible values would be N - new resource, U - updated resource or D - deleted resource. This column is used to form the view within the read schema.

  CONTENT_TASK - CHARACTER(25)

  The task name that performed the operation on this instance of the resource.

  CONTENT_TASKGRP - CHARACTER(25)

  The task group name that performed the operation on this instance of the resource.

• The constraints in the workspace write schema are relaxed.
  • Foreign keys to associated tables are dropped.
  • Unique indexes are relaxed to indexes. All non-unique indexes are restored.

The following figure illustrates the workspace data model for a managed operational resource. This type of resource has a corresponding table allocated in the workspace write schema to record changes within the workspace resulting from a preview. The read schema is defined as an alias to the write schema table so that the data is only viewable within the workspace.

The table within the workspaces has nearly the same structure as the production-ready schema with the following exceptions:

• The table has additional columns as follows:

  CONTENT_BASE - INTEGER

  This identifier indicates whether the data within this table is bootstrapped (1) or not (0). The data is not cleared when the workspace task group is completed.

• The constraints in the workspace write schema are relaxed.
  • Foreign keys to associated tables are dropped.
  • Unique indexes are relaxed to indexes. All non-unique indexes are restored.

The following figure illustrates the workspace data model for an unmanaged resource.

This type of resource does not participate in a workspace. The data in the production-ready schema is always accessed directly from within a workspace and as such, both the read and write schemas are aliases to the production-ready schema table.