Phần IV Cơ sở dữ liệu phân tán trong bài toán WSC (water supply company)

Phần IV Cơ Sở Dữ Liệu Phân Tán trong bài toán WSc (water supply company ) i. Giới thiệu khái quát về hệ thống và các vấn đề liên quan đến hệ thống. Dữ liệu trong bài toán WSC đợc phân tán theo phơng pháp Partition. Lý do về sự lựa chọn mô hình này đã đợc giải thích cụ thể trong phần giới thiệu về các mô hình phân tán dữ liệu. Những nội dung đợc trình bày sau đây sẽ chứng minh thêm tính đúng đắn của sự lựa chọn ấy. 1. Mô hình tổ chức và mô hình mạng của Công ty WSC. WSC là cơ quan đã có nhiều năm ứng dụng máy tính trong sản xuất và quản lý kinh doanh. Từ trớc năm 1997 WSC đã sử dụng hệ máy tính IBM sau đó là các chơng trình viết bằng FoxBase và FoxPro để quản lý và tính hoá đơn tiền nớc.Đến năm 1997 WSC đợc trang bị một hệ thống mạng máy tính hiện đại đòi hỏi một hệ thống phần mềm mới, ứng dụng công nghệ hiện dại, có khả năng kết nối diện rộng, quản lý lợng khách hàng lớn và đáp ứng yêu cầu nghiệp vụ là: - Đáp ứng 142 yêu cầu do các chuyên gia t vấn nớc ngoài đa ra bao trùm lên các lĩnh vực chính : 1. Khách hàng. 2. Yêu cầu và khiếu nại của khách hàng. 3. Đồng hồ vật t, thiết bị và các vị trí lắp đặt đồng hồ. 4. Biểu giá tiền nớc và tiền phụ thu. 5. Chỉ số đồng hồ và xử lý hoá đơn tiền nớc. 6. Thu tiền. 7. Thởng phạt khách hàng. 8. Phiếu công tác, thi công và nhân sự. - Đáp ứng yêu cầu nghiệp vụ hiện tại. a. Tổ chức công ty: Thể hiện qua cơ đồ hình 1.IV: Công ty cấp nước WSC Hoá đơn Chi nhánh Sài Gòn Chi nhánh Chợ Lớn Chi nhánh Gia Định Chi nhánh Thủ Đức Hợp đồng Khách hàng Các phòng chức năng NM nước Thủ Đức Xí nghiệp sửa chữa Xí nghiệp thi công Xí nghiệp vận hành Hình 1.IV :Tổ chức Công ty WSC b. Mô hình mạng của Công ty WSC: Tại trung tâm có hai máy chủ chính là Billing và Account đợc nối với nhau và chạy theo chế độ dự phòng. Khi máy thứ nhất có sự cố, thì máy thứ hai sẽ đảm nhận nhiệm vụ của máy chủ thứ nhất. Trong trờng hợp máy chủ ở chi nhánh có sự cố thì có thể khôi phục đầy đủ dữ liệu từ trung tâm. Trên cơ sở tổ chức mạng của Công ty WSC, Hệ quản lý khách hàng và xử lý hoá đơn tiền nớc đợc thiết kế theo mô hình CSDL phân tán trên môi trờng Oracle. Toàn bộ mạng máy tính của Công ty WSC đợc thể hiện qua hình vẽ sau: Sài Gòn Chợ Lớn Gia Định Thủ Đức Nhà máy nước Các phòng, ban Account Server Billing Server File Server Developer Server 2. Phạm vi của hệ thống. Hệ thống đáp ứng 142 yêu cầu do chuyên gia t vấn nớc ngoài đa ra và các yêu cầu nghiệp vụ hiện tại của WSC. Hệ đợc chia thành 4 phân hệ chính: - Hệ quản lý khách hàng. - Hệ xử lý hoá đơn và thu tiền. - Hệ tổng hợp và phân tích thông tin. - Hệ quản trị. Bao gồm hơn 120 module chơng trình, 70 module làm báo cáo, 30 database triggers, 105 thực thể, 83 thủ tục và hàm. Số bản ghi hệ thống phải lu khoảng 35 000 000 bản ghi. II. Mô hình phân tán dữ liệu tại WSC. 1. Phân tán chức năng hoạt động giữa trung tâm và chi nhánh tại WSC. - Trung tâm có các chức năng sau: + Quản lý các danh mục của hệ thống. + Các thông số hệ thống. + Các đơn vị trực thuộc: các chi nhánh, các nhà máy nớc. + Tạo báo cáo phục vụ cho công việc hoạt động trên toàn công ty. - Các chi nhánh có các chức năng sau: + Quản lý khách hàng. + Quản lý các dịch vụ đối với khách hàng. + Quản lý việc đọc đồng hồ của khách hàng. + Các báo cáo phục vụ cho công việc quản lý tại chi nhánh. 2. Mô hình dữ liệu chung tại WSC. Centeral Database Saigon Database Cholon Database Thuduc Database Giadinh Database Sơ đồ dữ liệu - Trung tâm: Dữ liệu tại trung tâm phải là hình ảnh đầy đủ về hoạt động của công ty. - Chi nhánh: Là một phần con của dữ liệu tại trung tâm, sao cho dữ liệu đó đủ để chi nhánh có thể thực hiện các chức năng của mình. 3. Mô hình dữ liệu phân tán tại WSC. Hệ thống của chúng ta sử dụng mô hình Basic Replication: Primary Site Replication và Advanced Primary Site Replication . - Primary Site Replication: Một số bảng đợc quản lý tại trung tâm và có các bản sao (read-only snapshot) của chúng tại các chi nhánh. Nh vậy, quyền làm chủ của bảng đó là thuộc trung tâm. - Advanced Primary Site Replication: Các bảng còn lại đợc chia thành nhiều phần riêng biệt, mỗi phần đợc quản lý bởi một chi nhánh. Tơng ứng với mỗi phần dữ liệu đó sẽ có một bản sao tại trung tâm, các bản sao của các phần riêng biệt của cùng một bảng tại trung tâm sẽ đợc gộp lại thành một đối tợng duy nhất (bản sao tổng hợp của các chi nhánh) để phục vụ cho quá trình xử lý dữ liệu. 4. Các chú ý khi tạo các bảng tại các chi nhánh trong cấu hình CSDL phân tán. - Đảm bảo các ràng buộc: Các ràng buộc của các bảng tại các chi nhánh (tức là tại một CSDL) đơng nhiên phải đợc đảm bảo. Ngoài ra các ràng buộc này phải đợc đảm bảo trên toàn bộ hệ thống dữ liệu (bao gồm nhiều CSDL). Oracle Server tại một CSDL không thể đảm bảo đợc điều này, do đó ta phải thiết kế một cách hợp lý để đảm bảo đợc điều này. - Phải xác định đợc nơi phát sinh dữ liệu cho một bảng nhất định (tại các chi nhánh, tại trung tâm hoặc cả hai). - Tên của các bảng: Các module tại các chi nhánh khi thực hiện thao tác lên CSDL có một yêu cầu là tên các đối tợng đợc sử dụng phải ổn định mặc dù đối tợng đó có thể có kiểu khác nhau (table, view, synonym, snapshot .). Trong khi đó các bảng đợc tạo ra cha chắc đã là các đối tợng truy nhập trực tiếp của các module, mà nó phải kết hợp với các đối tợng mới, do đó các bảng có thể phải đổi tên để cho các đối tợng có thể sử dụng tên đó. Nh vậy các module mới có thể truy nhập trực tiếp các đối tợng. Để đảm bảo cho mô hình dữ liệu phân tán đáp ứng đợc các chú ý trên ta phải thực hiện việc phân tích từng bảng trong hệ thống để có đợc những thông tin cần thiết trong bảng sau: Table name Owner Constraints Sequences Chú thích: - Table name: Là tên bảng theo thiết kế hiện tại. - Owner: Xác định xem quyền làm chủ bảng sẽ là trung tâm hay chi nhánh. Giá trị cho cột này có thể là một trong hai giá trị 'Trung tâm' hoặc 'Chi nhánh'. Quyền làm chủ ở đây có nghĩa là các thao tác Update lên bảng sẽ do phía nào thực hiện. Nếu một bảng nào đó có thể Update đợc từ cả trung tâm và chi nhánh thì mô hình dữ liệu phân tán ở trên sẽ không áp dụng đợc. - Constrains: Liệt kê tất cả các ràng buộc trên bảng theo thứ tự và khuôn dạng sau: Primary key: PK_NAME(column1,column2, .) Unique key: UK_NAME(column1,column2, .) Foreign key: FK_NAME(col1,col2, .) => REF_TABLE(ref_col1,ref_col2, .) - Sequences: Liệt kê tất cả các sequence mà bảng có sử dụng đến theo khuôn dạng sau: SEQ_NAME(column_use_this_sequence) Ví dụ 1: ABC: Assign billing cycle to customers. Owner: Branch. Constraints: + ASS_BCY_PK(CUST_ID, STT) + ASS_BCY_BLL_CYS_FK (BRANCH_ID,BC_CODE)=> BILLING_CYC (BARANCH_ID, CODE) + ASS_BCY_CUST_FK (CUST_ID) => CUSTOMERS(ID) Sequences: Notes: Names: + Branch: Table ABC + Center: Snapsshot ABC$TD, ABC$SG .; View ABC Ví dụ 2: ACTIVITIES_CUST_PARAMETERS Owner: Center Constraints: + ACTIVITY_C_PK(ID,CPRS_ID) + ACTIVITY_C_ ACTIVITY_FK(ID) => ACTIVITY(ID) + ACTIVITY_C_CPRS_FK (CPRS_ID) => CUST_ PARAMETERS(CPRS_ID) Sequences: Notes: Định nghĩa tại trung tâm và đợc sử dụng tại các chi nhánh trong các giao dịch với khách hàng. a. Cách đặt tên: - Nếu một bảng có nguồn gốc từ chi nhánh thì cách đặt tên nó nh sau: Tại các chi nhánh có các bảng cùng tên. Tại trung tâm: Các Snapshot có tên tạo bởi tên bảng ghép với dấu $ và mã chi nhánh, một View có cùng tên với bảng tổng hợp dữ liệu từ các Snapshot. Ví dụ : Bảng ABC có nguồn gốc từ các chi nhánh do đó nó có cách tổ chức nh sau: Tại các chi nhánh Sài Gòn, Chợ Lớn, Thủ Đức, Gia Định có các bảng tên là ABC. Tại trung tâm có 4 snapshot là ABC$SG, ABC$CL, ABC$TD, ABC$GD lấy dữ liệu từ các bảng ở các chi nhánh theo câu lệnh sau: CREATE SNAPSHOT ABC$SG AS SELECT * FROM ABC@saigon; và một View tổng hợp dữ liệu từ 4 chi nhánh: CREATE VIEW ABC AS SELECT * FROM ABC$SG UNION SELECT * FROM ABC$CL UNION SELECT * FROM ABC$TD UNION SELECT * FROM ABC$GD ; - Nếu một bảng có nguồn gốc từ trung tâm và dữ liệu của nó không phụ thuộc vào từng chi nhánh thì nó có cách đặt tên nh sau: Tại trung tâm có một bảng nh tên đã định. Tại mỗi chi nhánh có một Snapshot có cùng tên. Ví dụ: Bảng EXCHANGES có nguồn gốc từ trung tâm. Tại trung tâm có một bảng có tên là EXCHANGES. Tại mỗi chi nhánh có một Snapshot có tên EXCHANGES và đợc tạo ra nh sau: CREATE SNAPSHOT EXCHANGES AS SELECT * FROM EXCHANGES@wsc ; - Nếu bảng có nguồn gốc trung tâm nhng bản thân dữ liệu lại phụ thuộc từng chi nhánh thì nó cùng có cách đặt tên nh trên nhng khác ở câu lệnh tạo Snapshot. Ví dụ: Tạo Snapshot BILLS tại chi nhánh Chợ Lớn CREATE SNAPSHOT BILLS AS SELECT * FROM BILLS@wsc WHERE BRANCH_CODE = 'CL' ; b. Cách tạo các FK: Tại các chi nhánh: FK có liên quan đến các Snapshot (đến hoặc đi từ) vẫn đợc giữ nguyên, chỉ có tên bảng chứa Snapshot đợc sử dụng thay vì tên Snapshot. Tại trung tâm: FK có dính dáng đến các Snapshot đợc tách thành 4 FK. c. Tiến hành: Sử dụng Designer/2000 để thực hiện việc tạo các DDL scripts. - Tạo hai Application đại diện cho trung tâm và chi nhánh (CENTER và BRANCH), và tạo một Application tên là ALL_OBJECTS phục vụ cho mục đích tạo ra các FK của tất cả các bảng trong hệ thống một cách tổng thể. - Vào các ứng dụng WBL, WCA, WMA và WMI để share tất cả các bảng cho hai ứng dụng này một cách t ơng ứng (bảng nào có nguồn gốc trung tâm thì đa vào ứng dụng CENTER và ngợc lại bảng nào có nguồn gốc chi nhánh thì đa vào ứng dụng BRANCH. Share tất cả các bảng và sequence của 4 ứng dụng WBL, WCA, WMA, WMI cho ứng dụng ALL_OBJECTS. - Tại CENTER tạo tất cả các snapshot cần thiết tham chiếu đến các bảng của các chi nhánh theo cách đặt tên ở trên, sau đó tạo các Views tơng ứng tổng hợp thông tin từ các Snapshot. - Tại BRANCH tạo tất cả các Snapshot tham chiếu đến các bảng của CENTER, cần để ý đến điều kiện chọn lọc trong một số bảng có liên quan đến chi nhánh. Để tạo điều kiện chọn lọc khả thi, có một số cách nh sau: Bảng BRANCH tại chi nhánh chỉ chứa thông tin của riêng chi nhánh đó. Tuy nhiên một số module (mặc dù hoạt dộng tại chi nhánh) cần biết đến tất cả các chi nhánh khác. Bảng BRANCH chứa thông tin về tất cả các chi nhánh và có một bảngriêngcùngcấu trúc với BRANCH chứa thông tin về chi nhánh hiện tại. Bảng BRANCH chứa thông tin về tất cả các chi nhánh và trong bảng WSC_PARAMETERS có chứa một bản ghi chỉ ra mã của chi nhánh hiện thời. Ta sẽ chọn cách thứ 3 để thực hiện. Ví dụ với chi nhánh Chợ Lớn, ta thực hiện lệnh sau: INSERT INTO WSC_PARAMETERS (NAME, VALUE, DESCRIPTION) VALUES('BRANCH_CODE', 'CL', 'Mã của chi nhánh hiện tại') ; Khi đó điều kiện để lấy bảng BNR nh sau: CREATE SNAPSHOT BNR AS SELECT * FROM BNR@wsc WHERE BRANCH_ID IN SELECT BRANCH.ID FROM BRANCH, WSC_PARAMETERS WHERE BRANCH.BRANCH_CODE = WSC_PARAMETERS.VALUE AND WSC_PARAMETERS.NAME = 'BRANCH_CODE' ; Lần lợt vào 3 ứng dụng CENTER, BRANCH, và ALL_OBJECTS để thực hiện việc tạo ra các DDL script. III. Phân tán dữ liệu khách hàng trong WSC. Vì WSC là một hệ thống khá lớn, nên luận án xin chỉ trình bày chi tiết cách thức thực hiện phân tán một phần dữ liệu đầy đủ về Khách Hàng trong hệ thống WSC. 1. Giới thiệu các thực thể trong ứng dụng quản lí Khách Hàng. + Khách Hàng (CUSTOMER) : Hệ thống lu các thông tin về khách hàng: CUSTOMER_N0: Là mã số duy nhất ứng với mỗi khách hàng gọi là mã danh bộ, mã này đợc thiết lập dựa trên địa danh phố (STREET), phờng (WARD), tiểu khu (SUBAREA) và quận (DISTRICT). CONTRACT_N0:Mã của hợp đồng đợc kí kết giữa khách hàng và công ty về sử dụng nớc. CONTRACT_DATE: Ngày kí hợp đồng. NAME:Tên khách hàng. ADDRESS: Địa chỉ của khách hàng. INST_ADDRESS: Địa chỉ cài đặt đồng hồ. PAYMENT_TYPE: Kiểu thanh toán tiền của khách hàng. Một số các thuộc tính khác là: TELFAX, IDCARD_N0, SORT_NAME, STATUS, HOUSE_NUM, PERSON_NUM, BANK_ACCOUNT, BANK_OWNER, BANK_NAME, TOTAL_QUOTA, USAGE_LIST, WSC_SIGNED . Ngoài ra ứng với mỗi khách hàng chính còn có thể có các khách hàng phụ (SUB_CUSTOMER) đợc phân biệt bởi SUB_CUST_ID (nếu là khách hàng chính thì thuộc tính này nhận giá trị NULL). Với mỗi loại khách hàng thuộc một trong các loại: T gia,Tập thể,Cơ quan, Ngời nớc ngoài. Khách hàng có thể sử dụng nớc cho nhiều mục đích khác nhau nh dùng cho sinh hoạt và sản xuất và mỗi một đích có một giá biểu riêng. Một khách hàng thuộc một đợt tính hoá đơn/thu tiền/đọc số nhất định. Đồng hồ lắp đặt đợc lu đầy đủ các thông số kỹ thuật và vị trí vật lý. Một số các thực thể khác của ứng dụng quản lý Khách Hàng: + STREET: Phố + WARD: Phờng + SUBREA: Tiểu khu + DISTRICT: Quận + CUSTOMER CATEGORY: Loại khách hàng + ACTIVITY: Hoạt động + BRANCH: Chi nhánh + ACTIVITY_ASSIGN + CURRENCY: Tiền tệ + CUST NOTE: Các chú thích về khách hàng + AUDITTRAIL + SUB_CUSTOMER: Khách hàng phụ + USAGE ASSIGN: Kiểu sử dụng + METER_INSTALLATION: Cài đặt đồng hồ + SERVICE ORDER: Danh sách các dịch vụ + SUPPORT_CALL:Đăng kí khách hàng + COMPAINT : Yêu cầu khiếu nại của khách hàng Hiện nay tổng số khách hàng của công ty là 500,000 khách hàng. 2. Thực hiện phân tán CSDL. Tại trung tâm (Center) có các bảng dữ liệu nh trong kết quả của câu lệnh SELECT dới đây: SQL> select * from tab where tabtype='TABLE'; TNAME TABTYPE CLUSTERID ------------------------------ ------- --------- ACTIVITY TABLE BRANCH TABLE CCATS TABLE COMPLAINTS TABLE CURRENCY TABLE WSC_PARAMETERS TABLE WSC_USERS TABLE Các chi nhánh Sài Gòn, Gia Định, Chợ Lớn, Thủ Đức có các bảng dữ liệu: ACTIVITY_ASSIGN, AUDIT_TRAILS . SQL> select * from tab where tabtype='TABLE'; TNAME TABTYPE CLUSTERID ------------------------------ ------- --------- ACTIVITY_ASSIGN TABLE AUDIT_TRAILS TABLE CUSTOMERS TABLE CUST_NOTE TABLE DISTRICTS TABLE STREETS TABLE SUBAREA TABLE SUB_CUSTOMERS TABLE SUPPORT_CALL TABLE USAGE_ASSIGN TABLE WARDS TABLE WSC_PARAMETERS TABLE WSC_USERS TABLE Tại trung tâm có các Snapshot của các table tại các chi nhánh, và tại các chi nhánh cũng có Snapshot của dữ liệu trung tâm. Script thùc hiÖn viÖc t¹o Database link ®Ó kÕt nèi víi CSDL tõ xa DBlink.sql. KÕt qu¶ lµ 8 Database link (4 Database link lµ Center t¹i 4 chi nh¸nh vµ c¸c Database link: SaiGon, Gia§inh, Thu§c, ChoLon t¹i Center) ®îc t¹o ra: REM Create database links REM CENTER REM CENTER REM CENTER REM CENTER REM REM SAIGON REM GIADINH REM CHOLON REM THUDUC REM PROMPT Create database link CENTER for SAIGON branch CONNECT SAIGON/SAIGON@STU; Create database link CENTER connect to CENTER identified by CENTER using 'VPCP' ; PROMPT Create database link CENTER for GIADINH branch CONNECT GIADINH/GIADINH@STU; Create database link CENTER connect to CENTER identified by CENTER using 'VPCP' ; PROMPT Create database link CENTER for CHOLON branch CONNECT CHOLON/CHOLON@STU; Create database link CENTER connect to CENTER identified by CENTER using 'VPCP' ; PROMPT Create database link CENTER for THUDUC branch CONNECT THUDUC/THUDUC@STU; Create database link CENTER connect to CENTER identified by CENTER using 'VPCP' ; PROMPT Create database link SAIGON for CENTER site CONNECT CENTER/CENTER@VPCP; Create database link SAIGON connect to SAIGON identified by SAIGON using 'STU' ; PROMPT Create database link GIADINH for CENTER site CONNECT CENTER/CENTER@VPCP; Create database link GIADINH connect to GIADINH identified by GIADINH using 'STU' ; PROMPT Create database link CHOLON for CENTER site [...]... REM PROMPT CREATE SNAPSHOT WSC_ PARAMETERS$GD create snapshot WSC_ PARAMETERS$GD as select * from WSC_ PARAMETERS@GIADINH ; REM PROMPT CREATE SNAPSHOT WSC_ USERS$GD create snapshot WSC_ USERS$GD as select * from WSC_ USERS@GIADINH ; REM REM REM Sau khi Script Sna_cen.sql thực hiện tại Center ngoài các bảng dữ liệu cũ còn có thêm một tập các Snapshot từ các chi nhánh Bảng TAB1 trong phần phụ lục mô tả toàn bộ... 'CT_GROUP', list => ' ACTIVITY_ASSIGN$CL, AUDIT_TRAILS$CL, CUSTOMERS$CL, CUST_NOTE$CL, DISTRICTS$CL, STREETS$CL, SUBAREA$CL, SUB_CUSTOMERS$CL, SUPPORT_CALL$CL, WSC_ PARAMETERS$CL, WSC_ USERS$CL, ACTIVITY_ASSIGN$SG, AUDIT_TRAILS$SG, CUSTOMERS$SG, CUST_NOTE$SG, DISTRICTS$SG, STREETS$SG, SUBAREA$SG, SUB_CUSTOMERS$SG, SUPPORT_CALL$SG, WARDS$SG, USAGE_ASSIGN$SG, WSC_ PARAMETERS$SG, WSC_ USERS$SG, ACTIVITY_ASSIGN$GD,... USAGE_ASSIGN$GD REM WARDS$GD REM WSC_ PARAMETERS$GD REM WSC_ USERS$GD REM REM REM REM REM Create snapshots from THU DUC PROMPT Create snapshots from THU DUC REM THUDUC REM ACTIVITY_ASSIGN$TD REM AUDIT_TRAILS$TD REM CUSTOMERS$TD REM CUST_NOTE$TD REM DISTRICTS$TD REM STREETS$TD REM SUBAREA$TD REM SUB_CUSTOMERS$TD REM SUPPORT_CALL$TD REM USAGE_ASSIGN$TD REM WARDS$TD REM WSC_ PARAMETERS$TD REM WSC_ USERS$TD REM CONNECT... USAGE_ASSIGN$GD, CUST_NOTE$GD, DISTRICTS$GD, STREETS$GD, SUBAREA$GD, SUB_CUSTOMERS$GD, SUPPORT_CALL$GD, WSC_ PARAMETERS$GD, WSC_ USERS$GD, ACTIVITY_ASSIGN$TD, AUDIT_TRAILS$TD, CUSTOMERS$TD, CUST_NOTE$TD, DISTRICTS$TD, STREETS$TD, USAGE_ASSIGN$TD, SUBAREA$TD, SUB_CUSTOMERS$TD, SUPPORT_CALL$TD, WARDS$TD, WSC_ PARAMETERS$TD', next_date => SYSDATE, interval => 'SYSDATE + 1/24', implicit_destroy => TRUE); end;... SUB_CUSTOMERS$TD REM SUPPORT_CALL$TD REM USAGE_ASSIGN$TD REM WARDS$TD REM WSC_ PARAMETERS$TD REM WSC_ USERS$TD REM CONNECT CENTER/CENTER@VPCP; REM PROMPT Create snapshot ACTIVITY_ASSIGN$GD Create snapshot ACTIVITY_ASSIGN$GD as select * from ACTIVITY_ASSIGN@GIADINH ; REM PROMPT CREATE SNAPSHOT AUDIT_TRAILS$GD Create snapshot AUDIT_TRAILS$GD as select * from AUDIT_TRAILS@GIADINH ; REM PROMPT CREATE SNAPSHOT... Snapshot, xin giới thiệu Script: Log_cen.sql là một trong 5 Script thực hiện việc tạo các Snapshot log tại vị trí chủ REM This is log_cen.sql script REM Create snapshot log at CENTER site PROMPT Create snapshot log at CENTER site REM REM REM ACTIVITY REM BRANCH REM CCATS REM COMPLAINTS REM CURRENCY REM REM CONNECT center/center@vpcp; REM Create snapshot log on ACTIVITY; Create snapshot log on BRANCH; Create... THUDUC identified by THUDUC using 'STU' ; REM Database links created Một phần Script thực hiện việc tạo các Snapshot tại vị trí trung tâm Sna_cen.sql nh sau: REM Create snapshots from BRANCHS PROMPT Create snapshots from BRANCHS REM REM REM Create snapshots from GIA DINH PROMPT Create snapshots from GIA DINH REM GIADINH REM ACTIVITY_ASSIGN$GD REM AUDIT_TRAILS$GD REM CUSTOMERS$GD REM CUST_NOTE$GD REM . Phần IV Cơ Sở Dữ Liệu Phân Tán trong bài toán WSc (water supply company ) i. Giới thiệu khái quát về hệ thống và các vấn đề liên quan đến hệ thống. Dữ. III. Phân tán dữ liệu khách hàng trong WSC. Vì WSC là một hệ thống khá lớn, nên luận án xin chỉ trình bày chi tiết cách thức thực hiện phân tán một phần dữ