Scenario 2 describes how to model data about automobile insurance.
An automobile insurance policy contains information about both the policy holder and the policy itself. For example, policy holder information includes the name, address, and phone number of the customer. The policy is defined by a policy number, the description of the vehicle, including the vehicle identification number (VIN) and vehicle type, deductibles for comprehensive and collision loss, driver discounts, and so forth. Some of this information has a fixed number of values, whereas other information has a variable number of values. Each automobile policy has one policy number; however, different policy holders can differ in the number and type of discounts that they receive. A sample automobile insurance form is shown in Figure 1.
You can use different methods to model this type of data. Consider the situation in which you create one item type called Policy holder, as shown in Figure 2. This item type contains attributes such as name, address, and phone number. If this is the only item type that is defined, this model is not a good one because it does not include any content about the policy. It is merely a record containing information about customers with whom a company is doing business.
You could create one item type called Automobile policy, as shown in Figure 3. The root component might contain attributes such as policy number, those that describe the policy holder such as name, address, and phone number, and those that describe the policy such as VIN and vehicle type.
You can create a child component for this item type called Discount code. Because multiple values exist for discount codes (a customer can typically have more than one), a child component is a good place to include this type of information. Although this model does contain information about both the policy holder and policy itself, it is not the best model because of the problem of duplication of information.
Consider the situation in which a customer owns more than one car. A separate policy number exists for each car that the customer owns. If three policy numbers exist for a policy holder, three copies of the policy holder's address and phone number exist.
To eliminate the problem of duplication, you can create two item types: Policy holder (with attributes such as name, address, and phone number) and Automobile policy. Instead of putting an address attribute in the Automobile policy item type, you can create a reference attribute that you use to point to the Policy holder item type, as shown in Figure 4.
Using the system administration client, you create a reference attribute called Policy holder in the New Reference Attribute window. On the Attributes page of the New Item Type Definition notebook for the Automobile policy item type, you can associate this reference attribute with this item type.
One potential advantage of reference attributes is referential integrity. If you select the Restrict delete rule on the Attributes page, you can prevent a policy holder from being deleted when a policy still exists.
Customers might have more than one type of policy. For example, they might have auto insurance, homeowners insurance, and life insurance. Another way to use child components is to create an item type called Policy holder that has a child component called Policy. The Policy child component might contain a reference attribute that is used to point to an item in the Automobile policy, Home policy, or Life policy item type. These three item types then contain attributes that describe them. The cardinality of the child component determines how many policies a customer can have.
Another method that you can use to build a relationship between item types is linking, as shown in Figure 5. Using the system administration client, you create the Policy holder item type and classify it as a document item type. The Policy holder folders link to items from other item types, such as Automobile policy and Home policy, which contain information about these specific policies.
The IBM® Content Manager client applications allow documents or folders to be linked to folders. These items are not stored in a single place and contained within the folders as in a file system, but are linked to the folders. Documents and folders can be linked to multiple folders, whereas documents and folders typically are in one place in a file system. Using a web client or Client for Windows, users can paste documents or add them into folders, which automatically creates the link.
Document item types generally consist of multiple document parts. With the system administration client, you can associate document parts with document item types on the Document Management page.
The IBM Content Manager client applications require that each document item type has a base part. Typically, document item types have ICMBASE (base part), ICMANNOTATION (graphical annotations that overlay the base part), and ICMNOTELOG (separate textual comments).
The main content of an item in a document item type is stored as a base part. For example, the scanned picture of a car or insurance policy is the base part of an item in the Automobile policy item type. This item might then be added to a folder in the Policy holder item type, creating a link between the Automobile policy item and the Policy holder folder.
You can automatically populate folders by setting up auto-linking. Using the system administration client, open the folder item type and, on the Auto-linking page of the New Item Type Definition notebook, add a link to the document item type using the Folder contains link type. The advantage of auto-linking is that the system automatically places any document that you create in the client into the folder.
You can use foreign keys for validation purposes. You use them to establish a relationship with a unique or primary key to enforce referential integrity among tables. For instance, in a Policy holder item type, you can create a unique attribute called customer number. When you create an Automobile policy item type, that item type might also have the customer number attribute. You can then define a foreign key, using the Define Foreign Key window. The foreign key points to the customer numbers in the Policy holder item type so that you cannot enter an incorrect customer number when you enter data for the automobile policy.
