0% found this document useful (0 votes)
786 views9 pages

CH 10 Sol

The document describes a scenario for a magazine publishing company that is decentralizing management of customer subscriptions across four regional sites. It then asks a series of questions about how to design a distributed database to support the company's requirements. Key aspects of the design include: - Horizontally partitioning the CUSTOMER table by state and the INVOICE table by region. - Each regional site will manage its own fragments of CUSTOMER and INVOICE data. - The headquarters needs to be able to generate reports and queries across all regional data, requiring distributed request capabilities. - No distributed operations are needed between regional sites as data access is localized.

Uploaded by

mapsspam
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
786 views9 pages

CH 10 Sol

The document describes a scenario for a magazine publishing company that is decentralizing management of customer subscriptions across four regional sites. It then asks a series of questions about how to design a distributed database to support the company's requirements. Key aspects of the design include: - Horizontally partitioning the CUSTOMER table by state and the INVOICE table by region. - Each regional site will manage its own fragments of CUSTOMER and INVOICE data. - The headquarters needs to be able to generate reports and queries across all regional data, requiring distributed request capabilities. - No distributed operations are needed between regional sites as data access is localized.

Uploaded by

mapsspam
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 9

Answers to Problems

1. The following question is based on the DDBMS scenario in Figure P10.1.

Figure P10.1 The DDBMS Scenario for Problem 1

TABLES CUSTOMER PRODUCT INVOICE INV_LINE

FRAGMENTS N/A PROD_A PROD_B N/A N/A

LOCATION A A B B B

Site A

Site B

Site C

Specify the minimum type(s) of operation(s) the database must support (remote request, remote transaction, distributed transaction, or distributed request) in order to perform the following operations:

Teacher's Note: To answer the following questions, remind the students that the key to each answer is in the number of remote data processors that are accessed by each request/transaction. Ask the students to first identify how many remote DP sites are to be accessed by the transaction/request. Next, remind the students that a distributed request is necessary if a single SQL statement is to access more than one remote DP site. Use the following summary: Number of remote DPs Operation Request Transaction Remote Remote 1 >1 Distributed Distributed

Based on this summary, the questions are answered easily.

At Site C: a. SELECT * FROM CUSTOMER; This SQL sequence represents a remote request. b. SELECT * FROM INVOICE WHERE INV_TOTAL > 1000; This SQL sequence represents a remote request. c. SELECT * FROM PRODUCT WHERE PROD_QOH < 10; This SQL sequence represents a distributed request. Note that the distributed request is required when a single request must access two DP sites. The PRODUCT table is fragmented across two sites, A and B. In order for this SQL sequence to run properly, it must access the data at both sites.

d. BEGIN WORK; UPDATE CUSTOMER SET CUS_BALANCE = CUS_BALANCE + 100 WHERE CUS_NUM='10936'; INSERT INTO INVOICE(INV_NUM, CUS_NUM, INV_DATE, INV_TOTAL) VALUES ('986391', '10936', '15-FEB-2002', 100); INSERT INTO INVLINE(INV_NUM, PROD_CODE, LINE_PRICE) VALUES ('986391', '1023', 100); UPDATE PRODUCT SET PROD_QOH = PROD_QOH - 1 WHERE PROD_CODE = '1023'; COMMIT WORK; This SQL sequence represents a distributed request. Note that UPDATE CUSTOMER and the two INSERT statements only require remote request capabilities. However, the entire transaction must access more than one remote DP site, so we also need distributed transaction capability. The last UPDATE PRODUCT statement accesses two remote sites because the PRODUCT table is divided into two fragments located at two remote DP sites. Therefore, the transaction as a whole requires distributed request capability. e. BEGIN WORK;
INSERT CUSTOMER(CUS_NUM, CUS_NAME, CUS_ADDRESS CUS_BALANCE)

VALUES ('34210','Victor Ephanor', '123 Main St', 0.00); INSERT INTO INVOICE(INV_NUM, CUS_NUM, INV_DATE, INV_TOTAL) VALUES ('986434', '34210', '10-AUG-1999', 2.00); COMMIT WORK; This SQL sequence represents a distributed transaction. Note that, in this transaction, each individual request requires only remote request capabilities. However, the transaction as a whole accesses two remote sites. Therefore, distributed request capability is required. At Site A: f. SELECT CUS_NUM, CUS_NAME, INV_TOTAL FROM CUSTOMER, INVOICE WHERE CUSTOMER.CUS_NUM = INVOICE.CUS_NUM; This SQL sequence represents a remote request. Note that the request accesses only one remote DP site; therefore only remote request capability is needed.

g. SELECT * FROM INVOICE WHERE INV_TOTAL > 1000; This SQL sequence represents a remote request, because it accesses only one remote DP site. h. SELECT * FROM PRODUCT WHERE PROD_QOH < 10; This SQL sequence represents a distributed request. In this case, the PRODUCT table is partitioned between two DP sites, A and B. Although the request accesses only one remote DP site, it accesses a table that is partitioned into two fragments: PROD-A and PROD-B. Only if the DBMS supports distributed requests a single request can access a partitioned table. At Site B: i. SELECT * FROM CUSTOMER; This SQL sequence represents a remote request. j. SELECT CUS_NAME, INV_TOTAL FROM CUSTOMER, INVOICE WHERE INV_TOTAL > 1000; This SQL sequence represents a remote request. k. SELECT * FROM PRODUCT WHERE PROD_QOH < 10; This SQL sequence represents a distributed request. (See explanation for part h.)

2. The following data structure and constraints exist for a magazine publishing company. a. The company publishes one regional magazine each in Florida (FL), South Carolina (SC), Georgia (GA), and Tennessee (TN). b. The company has 300,000 customers (subscribers) distributed throughout the four states listed in Part a. c. On the first of each month an annual subscription INVOICE is printed and sent to all customers whose subscription is due (CUS_SUB_DATE) for renewal. The INVOICE entity contains a REGION attribute to indicate the state (FL, SC, GA, TN) in which the customer resides.
CUSTOMER (CUS_NUM, CUS_NAME, CUS_ADDRESS, CUS_CITY, CUS_STATE, CUS_SUB_DATE) INVOICE (INV_NUM, REG_CODE, CUS_NUM, INV_DATE, INV_TOTAL)

The company's management is aware of the problems associated with centralized management and has decided that it is time to decentralize the management of the subscriptions in its four regional subsidiaries. Each subscription site will handle its own customer and invoice data. The company's management, however, wants to have access to customer and invoice data to generate annual reports and to issue ad hoc queries, such as: List all current customers by region. List all new customers by region. Report all invoices by customer and by region. Given these requirements, how must you partition the database? The CUSTOMER table must be partitioned horizontally by state. (We show the partitions in the answer to 3c.) 3. Given the scenario and the requirements in Problem 2, answer the following questions: a. What recommendations will you make regarding the type and characteristics of the required database system? The Magazine Publishing Company requires a distributed system with distributed database capabilities. The distributed system will be distributed among the company locations in South Carolina, Georgia, Florida, and Tennessee. The DDBMS must be able to support distributed transparency features, such as

fragmentation transparency, replica transparency, transaction transparency, and performance transparency. Heterogeneous capability is not a mandatory feature since we assume there is no existing DBMS in place and that the company wants to standardize on a single DBMS. b. What type of data fragmentation is needed for each table? The database must be horizontally partitioned, using the STATE attribute for the CUSTOMER table and the REGION attribute for the INVOICE table. c. What must be the criteria used to partition each database? The following fragmentation segments reflect the criteria used to partition each database: Horizontal Fragmentation of the CUSTOMER Table By State Fragment Name C1 C2 C3 C4 Location Tennessee Georgia Florida South Carolina Condition CUS_STATE = 'TN' CUS_STATE = 'GA' CUS_STATE = 'FL' CUS_STATE = 'SC' Node name NAS ATL TAM CHA

Horizontal Fragmentation Of the INVOICE Table By Region Fragment Name I1 I2 I3 I4 Location Tennessee Georgia Florida South Carolina Condition CUS_STATE = 'TN' CUS_STATE = 'GA' CUS_STATE = 'FL' CUS_STATE = 'SC' Node name NAS ATL TAM CHA

d. Design the database fragments. Show an example with node names, location, fragment names, attribute names, and demonstration data. Fragment C1
CUS_NUM 10884 10993

Location: Tennessee
CUS_NAME James D. Burger Lisa B. Barnette CUS_ADDRESS 123 Court Avenue 910 Eagle Street

Node: NAS
CUS_CITY Memphis Nashville CUS_STATE TN TN CUS_SUB_DATE 8-DEC-2000 12-MAR-2000

Fragment C2
CUS_NUM 11887 13558

Location: Georgia
CUS_NAME Ginny E. Stratton Anna H. Ariona CUS_ADDRESS 335 Main Street 657 Mason Ave.

Node: ATL
CUS_CITY Atlanta Dalton CUS_STATE GA GA CUS_SUB_DATE 11-AUG-2000 23-JUN-2000

Fragment C3
CUS_NUM 10014 15998

Location: Florida
CUS_NAME John T. Chi Lisa B. Barnette CUS_ADDRESS 456 Brent Avenue 234 Ramala Street

Node: TAM
CUS_CITY Miami Tampa CUS_STATE FL FL CUS_SUB_DATE 18-NOV-2000 23-MAR-2000

Fragment C4
CUS_NUM 21562 18776

Location: South Carolina


CUS_NAME Thomas F. Matto Mary B. Smith CUS_ADDRESS 45 N. Pratt Circle 526 Boone Pike

Node: CHA
CUS_STATE SC SC CUS_SUB_DATE 2-DEC-2000 28-OCT-2000

CUS_CITY Charleston Charleston

Fragment I1
INV_NUM 213342 209987

Location: Tennessee
REGION-CODE TN TN CUS_NUM 10884 10993

Node: NAS
INV_DATE 1-NOV-2000 15-APR-2000 INV_TOTAL 45.95 45.95

Fragment I2
INV_NUM 198893 224345

Location: Georgia
REGION-CODE GA GA CUS_NUM 11887 13558

Node: ATL
INV_DATE 15-AUG-2000 1-JUN-2000 INV_TOTAL 70.45 45.95

Fragment I3 Location: Florida


INV_NUM 200915 231148 REGION-CODE FL FL CUS_NUM 10014 15998

Node: TAM
INV_DATE 1-NOV-2000 1-MAR-2000 INV_TOTAL 45.95 24.95

Fragment I4 Location: South Carolina


INV_NUM 243312 231156 REGION-CODE SC SC CUS_NUM 21562 18776

Node: CHA
INV_DATE 15-NOV-2000 1-OCT-2000 INV_TOTAL 45.95 45.95

e. What type of distributed database operations must be supported at each remote site? To answer this question, we must first draw a map of the locations, the fragments at each location, and the type of transaction or request support required to access the data in the distributed database.

Node Fragment CUSTOMER INVOICE Distributed Operations Required NAS C1 I1 none ATL C2 I2 none TAM C3 I3 none CHA C4 I4 none distributed request Headquarters

Given the problem's specifications, we conclude that no interstate access of CUSTOMER or INVOICE data is required. Therefore, no distributed database access is required in the four nodes. For the headquarters, the manager wants to be able to access the data in all four nodes through a single SQL request. Therefore, the DDBMS must support distributed requests. f. What type of distributed database operations must be supported at the headquarters site? See the answer for part e.

You might also like