Database Reference
In-Depth Information
way to indicate the criterion used—the customer's status—to determine the discount. This
is a rule that you must establish within the
physical
design of the database or the design of
the
database application.
Note
The manner in which you actually define and establish application-oriented busi-
ness rules is a topic that is beyond the scope of this topic. Some RDBMSs provide
tools that allow you to implement common application-oriented business rules re-
latively easily; most RDBMSs will require you to write programming code to im-
plement and enforce these rules.
Although both types of business rules are important, you'll focus on database-oriented
business rules during this stage of the database design process.
Note
Throughouttheremainderofthebook,I'llrefertodatabase-orientedbusinessrules
simply as
business rules.
Categories of Business Rules
Itwillbeeasier foryoutounderstandanddefinebusinessrulesifyoudividethemintotwo
distinct categories:
field specific
and
relationship specific.
Field-Specific Business Rules
Business rules under this category impose constraints on the elements of a field specifica-
tionforaparticularfield.Thenumberofelementsagivenruleaffectsdependsontheman-
ner in which you define that rule. For example, this rule only affects one element:
Orderdates are tobedisplayed inlongform,suchas“January 10,
2012.”
ThisruleaffectstheDisplayFormatelementoftheO
RDER
D
ATE
fieldinanORDERStable.
You establish this rule by modifying the Display Format element of the field specifications
for the O
RDER
D
ATE
field to indicate the manner in which the date should be displayed.
Here's a rule that affects more than one element:
We must be able to store a zip code for our Canadian customers.
This rule affects the Data Type, Character Support, and Display Format elements of the
fieldspecificationsfortheC
UST
Z
IPCODE
fieldinaCUSTOMERStable.Canadianzipcodes
