Beginning Database Design Solutions, 2nd Edition

13Extracting Business Rules

The previous chapters have built up a basic design for the Pampered Pet database. They gathered customer requirements, built a semantic object model and entity-relationship diagrams, and converted those into a relational model.

This chapter further refines the design by identifying business rules in the relational model and isolating them so they will be easy to modify in the future if necessary.

In this chapter, you'll see examples that identify:

• Required fields and other field-level constraints that are unlikely to change
• Sanity checks that are also unlikely to change
• Business rules that are more complicated or likely to change in the future

IDENTIFYING BUSINESS RULES

The text and exercises in Chapter 12, “Building a Data Model,” listed the fields required for the initial database design. For each field, that chapter gave the field's data type, whether the field is required, and its domain. That information describes most of the project's business rules.

Domain information usually includes simple “sanity check” constraints. These are conditions that basically verify the “laws of physics” for the database. For example, an item's cost cannot be less than $0.00. Exercise 5 in Chapter 12 discussed free pet clinics and outings, so it's possible that an item might be free, but it's hard to imagine the Pampered Pet's management charging less than nothing for a product.

Other sanity check conditions include field data types (the number of items is ...