Database Reference
In-Depth Information
taken per day or the total number of customers the company has, write it
down. Later you can use formulas to figure out table size, and ultimately
database size, based on the type of data stored.
Additionally, don't be afraid to ask about retention of each of the enti-
ties. For example, how long do you keep order information or customer
data? If the company intends to purge all information older than seven
years, you can expect the database to grow for seven years and then level
off a bit. If the company intends to keep data forever, then you may need
to build some sort of archive to prevent the database from suffering per-
formance hits later in its life. In either case, the time to start probing for
this information is during the requirements phase. If, when you are inter-
preting the requirements, you don't find any or all of this type of data, go
back to the customer and ask. If nothing else, this practice gets people
thinking about it and there are no surprises later when the database ad-
ministrators ask about data purging.
Once you have completed the requirements evaluation, you should have
several pieces of documentation that you will need in the next phase, the
creation of the logical model. In this chapter we've talked about most of
this documentation, but we want to take this opportunity to review the
documents you should now have. The following is a list of each piece of
documentation you should have at this point.
Entity List
You should have a list of the entities that the requirements have dictated.
This list won't likely be complete at this point; however, all the entities
that the business cares about should be on the list. Later you may find that
you will need other entities to support extended relationships or to hold
application-specific data. This list should include the following:
The name of the entity
■
A description of the entity
■
From which requirement the entity was discovered (e.g., interview
with CEO)
■
Search WWH ::
Custom Search