Database Reference
In-Depth Information
(and its eventual database) would have to support. We now need to narrow
that list to a final list of the most likely suspects.
For example, Table 7.1 shows the list of nouns gathered during re-
quirements gathering, along with a brief description of what the noun
refers to. You'll recognize this is almost the same list from Chapter 6; how-
ever, we've added some entities, as we discuss in a moment.
This list of entities accounts for some specific issues that arise when
you try to relate these entities to one another, as well as issues created by
moving to an online system. Because the other entities have been dis-
cussed in detail, we'll review the new ones and explain why they exist.
Lists and List Items
These entities account for a type of information that exists only to
support the system and is not accounted for in traditional require-
ments gathering. In this case, we realized that we would need to
track the status of shipments, and because items in a single order
can be shipped in separate shipments, we need to relate the status
of all order items and the shipment they are part of. Additionally, we
need a flexible list of status codes, because that kind of data can
change based on business rules. Finally, we realized that this subset
of information is not the only lookup-style information we might
need. In the future, there may be needs to create lists of information
based on status, product type, and so on. So we built a flexible solu-
tion by creating these generic Lists and List Items entities. Lists rep-
resents any list of information we might need—for example, the status
of an order. List Items is simply a lookup table of potential items for
the list—in this case, the status codes. With this solution, we can add
any type of list in the future without adding other entities.
■
Product Attributes
When addressing the existence of a product, you must account for
where that product comes from and how it is packaged and sold.
Additionally, for a company like MVM, it is necessary to deal with
the fact that different products have different kinds of attributes.
For example, a guitar does not have all the same physical attributes
as a saxophone (although there are some attributes in common). To
model this scenario correctly, it became necessary to create a
Product Attributes entity that represents various types of attributes
a product can have. So instead of including every possible attribute
for all products in the Product entity, we've essentially created an
■
Search WWH ::
Custom Search