Database Reference
In-Depth Information
CustomerNo
2235
5598
6699
7755
9655
0089
0109
0412
Name
Address
Phone
CreditCde
Balance
CUSTOMER
data file
Rolland
Williams
Jones
Hathaway
Cervino
Cuccia
Harreld
McKeown
CustomerNo
2235
5598
6699
7755
9655
Name
Address
Phone
CreditCde
Balance
Horizontal
Partitioning
Rolland
Williams
Jones
Hathaway
Cervino
CustomerNo
0089
0109
0412
Name
Address
Phone
CreditCde
Balance
Cuccia
Harreld
McKeown
CustomerNo
2235
5598
6699
7755
9655
0089
0109
0412
Name
Address
Phone
CustomerNo
2235
5598
6699
7755
9655
0089
0109
0412
CreditCde
Balance
Vertical
Partitioning
Rolland
Williams
Jones
Hathaway
Cervino
Cuccia
Harreld
McKeown
Figure 12-20
Horizontal and vertical partitioning.
•
Taking advantage of special features of the DBMS such as prefetching of blocks
that are likely to be needed for the next processing.
Preconstructed Joins
Consider three related tables for a product distributing business: CUSTOMER,
PRODUCT, and SALE. The CUSTOMER table contains data about each cus-
tomer. The PRODUCT table contains data about each product. The SALE table
contains data such as date of sale, product sold, manufacturer of product, customer
number, sale representative identification, and so on.
Assume that a large number of data retrieval requests require data from all
three of these tables. How will these data retrieval requests be satisfied? For every
such request, the three tables must be joined and then the requested data have to
be retrieved. In such situations, joining these tables for every request causes big
overhead and slows the data retrievals. Is there an alternative to these numerous
joins?
Suppose you do the joins before hand and preconstruct another table as a
directory containing join-attribute values with pointers to the CUSTOMER and
PRODUCT table rows. If you do that, then all the corresponding data requests can
Search WWH ::
Custom Search