A validation rule identifies a set of values that an attribute is allowed to take; it constrains or restricts the domain of values that are acceptable. These values have meanings in both an abstract and a business sense. For example, “person-name,” if it is defined as the preferred form of address chosen by the PERSON, is constrained to the set of all character strings. You can define any validation rules or valid values for an attribute as a part of the attribute definition. You can assign these validation rules to an attribute using a domain. Supported domains include text, number, datetime, and blob.
Definitions of attributes, such as codes, identifiers, or amounts, often do not lend themselves to good business examples. So, including a description of the attribute's validation rules or valid values is usually a good idea. When defining a validation rule, it is good practice to go beyond listing the values that an attribute can take. Suppose you define the attribute “customer-status” as follows:
Customer-status: A code that describes the relationship between the CUSTOMER and our business. Valid values: A, P, F, N.
The validation rule specification is not too helpful since it does not define what the codes mean. You can better describe the validation rule using a table or list of values, such as the following table:
|
Valid Value |
Meaning |
|---|---|
|
A: Active |
The CUSTOMER is currently involved in a purchasing relationship with our company. |
|
P: Prospect |
Someone with whom we are interested in cultivating a relationship, but with whom we have no current purchasing relationship. |
|
F: Former |
The CUSTOMER relationship has lapsed. In other words, there has been no sale in the past 24 months. |
|
N: No business accepted |
The company has decided that no business will be done with this CUSTOMER. |
| Copyright © 2011 CA. All rights reserved. | Tell Technical Publications how we can improve this information |