INTERPRETING REQUIREMENTS - A Developer's Guide to Data Modeling for SQL Server - page 139

document all these rules when you are interpreting the business require-
ments. Table 6.3 provides some of the types of business rules that you
should enforce and shows the method you will likely use to enforce them
using SQL Server.

Table 6.3 B u s i n e s s R u l e s Yo u S h o u l d E n f o r c e i n Yo u r D a t a M o d e l o r i n S Q L S e r v e r

Business Rule Enforcement Example

Data must be a certain Data Type Product SKU numbers are always whole

type. integers.

Information cannot exceed Data Type-Length Due to display limitations on the Web site, a

a given length. product description can contain no more than

500 characters.

Data must follow a specific Constraint An e-mail address must follow the convention

format. [e-mail], where X is some piece of

string data and YYY is a domain type such as
.COM, .NET, .GOV, etc.

Some items can exist only Primary Key-Foreign An order must be owned by customer.

as part of or when owned Key Relationship An order detail item must be part of an order.

by another item.
Information must contain Constraint For an address to be valid, it should contain at

some number of characters. least five characters. If it contains fewer than

five, the data is likely to be incomplete or
incorrect.

Given a set of similar data, Constraint When collecting a customer's home, work, and

no one piece of informa- cell phone number, it is not required that they

tion is required, but at least provide all phone numbers but it is required

one of the set is required. that they provide at least one of the phone

numbers.

By no means does Table 6.3 provide a comprehensive list of the types
of rules you are likely to encounter, but it gives you an idea of what you can
and should do in your database. You will notice that several scenarios can
be handled in your data model only. It's easy to handle data types, lengths,
and relationships when you build your logical model. Other business rules
are a bit more complex and need to be handled later when you implement
your physical model on SQL Server.
For now, as you are interpreting your requirements, be sure to use the
appropriate entity to document any rules that come along. Whenever you
are told that something needs to work a certain way or be stored a certain