Performance Tuning for Content Manager

Chapter 5. Designing and configuring for performance 115

looks for the user, the tested ACL, and the specific privilege in the

ICMSTCompiledACL table. This table holds a row for every privilege in every

ACL that every user holds. Note that a large number of users and a large number

of ACLs could make this a very large table.

5.5.3 Data model

The primary issue for the data model is to capture the data required by the

business problem. When that is established it can be massaged for performance.

As mentioned earlier, the Library Server holds the metadata and system control

data and is primarily a database application. That means that the same

principles that are applied to good database design can also be applied to the

Content Manager data model. Normalize the data to reduce the table size and

de-normalize for performance. Add indexes to fields that are queried. Cluster the

table into a sequence that reflects the way data is accessed.

Normalizing the data means to identify data that might be repeated for one

particular entry and extract that data to a separate database table. Imagine that

we wish to record information about a customer for whom we have an application

form image. That customer might have one name but two addresses, a business

address and a residential address. To represent this in our system, we could

create two rows, one for each of this customer’s addresses. When we search on

his or her name we find both addresses. We also see that the database table has

the customer’s name and possibly other details repeated in our database, which

might not be the most efficient use of our resources, especially as the number of

our customers grows. One solution is to change our database model and store

the data that gets repeated (in this case, the customer’s name and other

customer details in one table and the address data in another table), and

maintain a database relationship between the two tables.

In Content Manager, this means implementing folders, links, references, or child

components as needed. Refer to the System Administration Guide for more

details about these components and additional information about how to model

your data.

In the example above, this could be implemented as a root and child component

relationship. The customer’s name would be part of the root data, and their

addresses would become entries in a child component attached to the root. It is

also possible to model this using links. The customer name information may be

modelled as a root component that is linked to other root components, which

each hold the address information.

Using our previous example, we might have several applications or other types of

documents that relate to this same customer. We could have his or her name

recorded many times. This could be another opportunity to reduce the amount of