Database Reference
In-Depth Information
would lead you to store the data in a varchar column. An SKU num-
ber that is solely numerals may point you toward an int.
The intended user of the form
The intended user can offer valuable insight into possible security
implications and work flow. Understanding who can place an order
will help you later when you need to add security to the database so
that only the appropriate people can see certain data. Additionally,
understanding how a user places an order or how an inventory count
is recorded can help you to better understand the work flow and
help you to design the model accordingly.
■
The restrictions placed on users
Restrictions that a form places on its user can be clues to data re-
quirements or business rules. If the customer information form asks
for three phone numbers (such as home, work, and mobile) but re-
quires only that one be filled in, you may have a business rule that
needs to be implemented. Additionally, a form may limit the cus-
tomer's last name to 50 letters; this probably means that you can
limit the data type of last name to 50 characters.
■
Interpreting Use Cases
As we discussed in Chapter 5, use cases help define a process without all
the technical language of the process or system getting in the way. Because
you should have a basic understanding of use cases at this point, we next
talk about how you go about pulling data modeling requirements from a
use case. Take a look at the use case diagram in Figure 6.3 and the use case
documentation in Figure 6.4.
Let's look at this use case in detail and extract the modeling require-
ment. We will look at the two principals in the use case: warehouse em-
ployees and customers. In terms of our data model, we already have an
employee and a customer entity, so it looks as if we have all the principals
in our model. Next, we look at the actual use cases, of which there are five:
Add Items to Web Site Cart
■
Checkout on Web Site
■
Print Packing Slip
■
Pack Order
■
Ship Order
■
Search WWH ::
Custom Search