Database Reference
In-Depth Information
tree to the target data. This access method requires the user to be very familiar with the
structure of the database.
One advantage to using a hierarchical database is that a user can retrieve data very quickly
because there are explicit links between the table structures. Another advantage is that ref-
erentialintegrityisbuiltinandautomaticallyenforced.Thisensuresthatarecordinachild
table must be linked to an existing record in a parent table, and that a record deleted in the
parent table will cause all associated records in the child table to be deleted as well.
Note
In the following examples, table names within the text appear in all capital letters
(suchasVENDORS)andfieldnameswithinthetextappearinsmallcapitalletters
(such as V
ENDOR
ID N
UMBER
).
A problem occurs in a hierarchical database when a user needs to store a record in a child
table that is currently unrelated to any record in a parent table. Consider an example us-
ing the Agents database shown in
Figure 1.1
.
A user cannot enter a new entertainer in the
ENTERTAINERS table until the entertainer is assigned to an agent in the AGENTS table.
Recallthatarecordinachildtable(inthiscase,ENTERTAINERS)mustberelatedtoare-
cordintheparenttable(AGENTS).Yetinreallife,entertainerscommonlysignupwiththe
agency well before they are assigned to specific agents. This scenario is difficult to model
in a hierarchical database. The rules can be bent without breaking them if a dummy agent
record is inserted in the AGENTS table; however, this option is not really optimal.
This type of database cannot support complex relationships, and there is often a problem
with redundant data. For example, there is a many-to-many relationship between clients
and entertainers—an entertainer will perform for many clients, and a client will hire many
entertainers.Youcan'tdirectlymodelthistypeofrelationshipinahierarchicaldatabase,so
you'll have to introduce redundant data into both the SCHEDULE and ENGAGEMENTS
tables.
• The SCHEDULE table will now have client data (such as client name, address, and
phone number) to show for whom and where each entertainer is performing. This
particular data is redundant because it is currently stored in the CLIENTS table.
• The ENGAGEMENTS table will now contain data on entertainers (such as enter-
tainer name, phone number, and type of entertainer) to indicate which entertainers
are performing for a given client. This data is redundant as well because it is cur-
rently stored in the ENTERTAINERS table.
