Database Reference
In-Depth Information
The problem with this redundancy is that it opens up the possibility of allowing a user to
enter a single piece of data inconsistently. This, in turn, can result in producing inaccurate
information.
Ausercansolvethisprobleminaroundaboutmannerbycreatingonehierarchicaldatabase
specifically for entertainers and another specifically for agents. The new Entertainers
database will contain only the ENTERTAINERS table, and the revised Agents database
will contain the AGENTS, CLIENTS, PAYMENTS, and ENGAGEMENTS tables. The
SCHEDULE table is no longer needed in the Entertainers database because you can define
alogicalchildrelationshipbetweentheENGAGEMENTStableintheAgentsdatabaseand
the ENTERTAINERS table in the Entertainers database. With this relationship in place,
you can retrieve a variety of information, such as a list of booked entertainers for a given
client or a performance schedule for a given entertainer.
Figure 1.2
shows a diagram of the
new model.
Figure 1.2. Using two hierarchical databases to resolve a many-to-many relationship
As you can see, a person designing a hierarchical database must be able to recognize the
need to use this technique for a many-to-many relationship. Here the need is relatively ob-
vious, but many relationships are more obscure and may not be discovered until very late
