Restricting the Range of Values

Having identified the base data type for your domain, the next step is to specify the values within that data type's range that are valid for the domain. Sometimes the easiest way to do this is by specifying a rule: "Quantities must be positive whole numbers."

Sometimes it's simpler to list the valid values for a domain. "Region must be one of these: Northwest, Northeast, Central, Southern." In this instance, you will almost certainly want to include the domain as an entity in the data model. This is far easier than typing the values everywhere they're referenced, and also allows them to be easily changed after the system has been implemented.

The only possible exception to this rule is when the domain values are few in number and cannot possibly change. Say, for example, that you're modeling a questionnaire and an exam, and you have an Answer domain that consists of the values ""True" and "False". There is no point in modeling these two options as an entity. There are no other possible values, and referencing a table during implementation will almost certainly be more trouble than typing in the rule directly.

You will also use an entity to model domains that must be defined using more than one attribute. The best example of this is the domain of State. If you must account for multiple countries, you cannot determine whether a given state value is valid without reference to the country specified.

If a customer is located in Australia, for example, "New South Wales" is a valid state, but "Alabama" is not. In this case, the domain look-up entity would consist of both the Country and State attributes. This example is not strictly a domain definition, and it's modeled using required relationships in the E/R model. It is, however, easy to think of this sort of situation as a kind of composite domain, and treat it as such.

After all, the point here is to simplify the task of identifying the constraints that pertain to the system, and bending the domain definition for domains that appear repeatedly in the data model saves time and reduces the chance of error.

Your domain specification must also indicate whether nulls or zero-length strings, or both, are acceptable values for attributes defined on the domain. It's useful to explicitly declare this in your definition even if you're modeling the range using a system entity, in which case the nullability can be determined by the relationship between the two entities.

Performing the domain analysis and identifying the list of attributes for any given entity are closely related, iterative processes. In actual practice, you'll probably find it most effective to define the domains at the same time that you're listing the attributes. If the domain of an attribute is already defined, you can simply list it. If not, you can define the domain while you have an example in front of you.

During this process, you might find that certain attributes have restrictions in addition to those defined for the domain. This is perfectly proper and not at all unusual. You might have defined an Event Date domain, for example, that represents the date on which any event can occur. This date is restricted to dates after the company began trading. In the Sales Order example, both the Order Date and the Shipping Date would be defined on the Event Date domain. The Shipping Date attribute, however, must also be after the Order Date. This is an entity-level constraint and should be listed as such in the entity description.

In defining domain constraints (and additional attribute constraints, for that matter), you should try to be as specific as possible without compromising usability. We'll discuss this in greater detail in Part IV, but at this point you should be aware that the more precisely you define a domain, the more assistance you can provide users. If you accidentally eliminate values, however, you will get in the users' way and can ultimately make the system unusable.

Defining the Format

It's not strictly necessary, but it's often a good idea to specify the appropriate format for a domain. If you specify once that all dates must be displayed as DD-MMM-YYYY, you need never do it again.