Building a Data Model - High-Performance Web Databases: Design, Development, and Deployment - page 219

Normalization does not ensure that the model correctly reflects the busi-
ness meaning of data requirements. Therefore, normalization should be
employed as a refinement technique (step LDM7) only after completing a thor-
ough business analysis using the techniques in steps LDMI through LDM6.

Normalization also does
not fully address business rules. These should be part of a data model to
ensure that not only the structure but the values of the data correctly
reflect business operations. Steps LDM3 through LDM5 already have
uncovered the most significant business rules — those governing integrity
of entity and foreign key attributes. At this point, two additional types of
attribute business rules can be identified by:

Determining Additional Attribute Business Rules.

• Determining domains (constraints on valid values that attributes may
assume). (Step LDM8.)
• Determining triggering operations (rules that govern the effects of
insert, delete, and update operations on other entities or other
attributes within the same entity). (Step LDM9.)

The term domain includes data type, length, format or mask, uniqueness
of values, null support (whether a value must be present), allowable val-
ues, default value if applicable, and business meaning. Domains verify
whether values assigned to an attribute make business sense. They also
help in determining when it makes sense to compare or manipulate values
of two different attributes.

The term triggering operation refers to the most generalized form of
business rule, encompassing domains and key business rules, as well as
other attribute business rules. These elements reflect the user's under-
standing of all rules that make some sets of data values correct and others
incorrect in the business world (e.g., for a given RENTAL-AGREEMENT,
END-DATE must be later than BEGIN-DATE).

The intent in defining business rules is to clarify all data-driven con-
straints on the data values. In other words, those rules that always hold
true are defined, regardless of any particular processing requirements.
Because these rules are information system-independent, they are defined
as part of the data design rather than as part of the information system
design. If instead they are treated as part of the information system, they
would have to be completely, consistently, and redundantly specified as
part of every information system accessing the data.

The final logical design steps combine user views
into one consolidated logical data model:

Integrating User Views.

• Combining user views into one model. (Step LDMIO.)
• Integrating with existing data models. (Step LDM 1 1.)
• Analyzing for stability and growth. (Step LDMI2.)