Domain Analysis

In Figure 12-6, the attribute listing takes the form Name:Domain. Many analysts ignore the existence of domains and specify the attributes directly in terms of their data types and constraints. So if you ignore this step of the process, you'll be in good company. You won't be correct, but it's unlikely that anyone will fault you for it.

The reason I perform domain analysis in my own work, and recommend that you do so as well, is that it saves work and provides additional information. As far as I'm concerned, anything that's easier and better is a good idea. And this task has the added advantage of being technically correct, as well.

Let's take just one example: The CompanyName and IndividualName attributes in Figure 12-6 all specify that they derive their values from the domain of Name.

We can now define the Name domain as follows:

"A string of one or more words in proper case, with a maximum length of 75 characters. Only characters and the punctuation marks period (.) and comma (,) are allowed."

We have to define the domain only once, and we can reference it any number of times throughout the system. We could have defined these constraints for each applicable attribute, but why bother? Furthermore, because these attributes are defined on the same domain, we know that they can be logically compared. This wouldn't necessarily be clear if we had defined the attributes directly.

Finding the customer with the same value in the CompanyName field as in the IndividualName field might not be the most useful thing to do, but it is at least a possible thing. The same could not be said of comparing company names to customer numbers that might, coincidentally, have the same structure and constraints.

The technical definition of a domain is "the set of values from which an attribute can draw its values." This is conceptually straightforward, but how does one define a domain? Essentially, you need to identify three things:

Choosing a Data Type

The first step in defining a domain is to choose the core data type that will be used in the database schema to represent it. This is one instance where it's practical to break the rule about separating the database schema from the conceptual data model.

The data type serves as a shorthand description of a range of values. While "Integer" is not a domain unless you're modeling mathematics, values of the domain "Quantity" are almost certainly integers. I wouldn't recommend getting too involved with the specifics of database engine types, however. At this point, the choice of database engine is still subject to change.

The "data type" of a domain can also be another domain. You might have already defined a generic Date domain, which specifies, for example, that all dates in the system must be on or after 1 January 1900 and formatted using a four-digit year. It's perfectly acceptable to define the Event Date as "A Date after 23 October 1982 (the date on which trading commenced)".