Designing Applications Based on Conflict Integrity Issues

The Notes/Domino database architecture is not relational; rather, it is essentially a flat file database. What this means is that unlike a relational database, where redundancy is minimized through normalization and linked tables, redundancy is not only common, but it is often necessary in your Notes/Domino applications. That being said, your goal should be to minimize redundancy as much as possible because it leads to wasted storage and obsolete data.

Consider the example of a customer relationship management application that includes company documents and contact documents. In this example, the contacts are children of the company document and need to inherit certain key pieces of information from the company if they are to display properly in the views. If the contact document does not store the company name value, the document does not display properly in views based on the company name. Although you could look up this value dynamically in a form by using @DbLookup or the GetDocumentByKey method of NotesView in LotusScript, it must reside in the document to be displayed in views. After the value has been inherited into the child document, that value is not refreshed automatically. So if the company name changes, all the documents for that company will contain obsolete information. The only remedy to this is to create an agent that updates the company name field in the contact documents if the name is changed.

In a relational database, the company name is not likely to be stored with the contact; rather, the contact record is probably linked to the company record through a common key. If the company name changes, as in the earlier example, users automatically see the new information because of the dynamic link and the lack of redundancy. As stated earlier, in some cases, redundancy is required to make the application function correctly. However, you should plan on keeping redundancy to a bare minimum in your application.