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
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