Database Reference
In-Depth Information
Some people prefer not to get so specific at this point. Rather, they will examine the various columns
and determine a preliminary list of entities, as shown in Figure 6-18.
Orders
Customer
Rep
Part
208
FIGURE 6-18
Tentative list of entities
After examining the functional dependencies, they will refine this list, producing a list similar to the one
shown in Figure 6-19. At this point, they will create tables for these entities and position each column in the
table in which it seems to fit best.
Invoice
Customer
Rep
Part
Orders
OrderLine
FIGURE 6-19
Expanded list of entities
Whichever approach you take, this kind of effort is certainly worthwhile; it gives you a better feel for the
problem when you interact with the user. You can change your work based on your interview with the user.
Even if your work proves to be accurate, you still need to ask additional questions of the user. These ques-
tions include the following:
What names do you think are appropriate for the various entities and attributes?
What synonyms are in use?
What restrictions exist?
What are the meanings of the various entities, attributes, and relationships?
If the organization has a computerized system, current file layouts can provide you with additional infor-
mation about entities and attributes. Current file sizes can provide information on volume. Examining the
logic in current programs and their operational instructions can yield processing information. Again, how-
ever, this is just a starting point. You still need further information from the user, which you can obtain by
asking questions such as these:
How many invoices do you expect to print?
Exactly how are the values on the invoice calculated, and where do they come from?
What updates must be made during the invoicing cycle of processing?
What fields in the Customer table will be updated?
ONE-TO-ONE RELATIONSHIP CONSIDERATIONS
What, if anything, is wrong with implementing a one-to-one relationship by simply including the primary key
of each table as a foreign key in the other table? For example, suppose each Premiere Products customer has
a single sales rep and each sales rep represents a single customer. Applying the suggested technique to this
one-to-one relationship produces two tables:
Rep (RepNum, LastName, FirstName, CustomerNum)
Customer (CustomerNum, CustomerName, RepNum)
In practice, these tables would contain any additional sales rep or customer columns of interest in the
design problem. For the purposes of illustration, however, assume these are the tables
'
only columns.
