Database Reference
In-Depth Information
statement, it may look as though a payment is simply an attribute of the
order, but that interpretation is mistaken. Later when the various payment
methods are described, we see that there is much more to payment meth-
ods than meets the eye. For this reason, we listed it as an entity, something
that may change as we gather more data. Also watch out for words or
phrases that could change the meaning of the data, such as
usually, most
of the time,
or
almost always.
If the customer says that orders are usually
paid for with one form of payment, you will want to clarify to make sure
that the database can handle the “usually” as well as the “rest of the time.”
Next, let's go over the same statement for key words that may describe
attributes. At this early point, we wouldn't expect to find all or even most
of our attributes. Once we have a complete list of entities we will return to
the organization and hammer out a complete list of the required attributes
that will be stored for each entity. Just the same, if you run through the
statement again, you should find a few attributes. Following is a new entity
list with the attributes we can glean from the statement:
Customer
Address
■
Order
■
Order Detail, Order Item
Quantity
■
Product
■
Payment
Credit Cards
Gift Cards
Electronic Check
■
Employee
■
We now know that we must track the customer's address and the quan-
tity ordered for an order item. It's not much, but it's a start. We could prob-
ably expand Address into its component parts, such as city, state, ZIP, and
so on, but we need a little more detail before we make any assumptions.
Again, payment offers a bit more complexity. The only further details we
have about payment are the three payment methods mentioned: credit
cards, gift cards, and electronic checks. Each of these seems to have more
detail that we are missing, but we are reluctant to split them into separate
entities; it's bad modeling design to have multiple entities that contain the
Search WWH ::
Custom Search