Cơ sở dữ liệu phân tán 1

9 724 4
Cơ sở dữ liệu phân tán 1

Đang tải... (xem toàn văn)

Thông tin tài liệu

Cơ sở dữ liệu phân tán

Chơng 10. Quản lí dữ liệu phân tánLợi ích chính của DDM là khả năng truy nhập dữ liệu đợc nằm ở nhiều điểm khác nhau trong một kiểu trong suốt ngời sử dụng cuối. đồng thời, DDM gồm cả việc giữ hầu hết các dữ liệu địa phơng ở những nơi thực sự cần dữ liệu.DDM là một trong những kiểu xử lí phân tán hợp tác đợc thực hiện trong kiến trúc khách hàng/ dịch vụ. Kiến trúc khách hàng/ dịch vụ cho một giải pháp lí tởng cho các yêu cầu của DDM , nên hầu hết các thể hiện kiến trúc khách hàng/ dịch vụ ngày nay là các hệ quản trị sở dữ liệu phân tán (DDBMS). Môi trờng DDM đợc đặc trng hoá bởi 2 cách phân tán (hình 9.5.3)Trong khi đó một số vấn đề hiện nay là: phân tán dữ liệu nh thế nào? truy nhập dữ liệu nh thế nào? tích hợp dữ liệu? Tính vững chắc dữ liệu ? sẽ đ ợc làm rõ trong chơng này.1. các phơng pháp phân tán dữ liệuDDM xét dữ liệu (cơ sở dữ liệu ) đợc phân tán trên nhiều node. Phân tán dữ liệu trên nhiều node những điểm lợi:- dữ liệu đợc đặt gần nguồn của nó hơn.- thích ứng dữ liệu cao hơn bằng cách đặt nhiều bản copy của dữ liệu khẩn tại nhiều nơi khác nhau. tránh đợc điểm đơn thất bại.- Hiệu quả truy nhập cao hơn tăng khẩ năng quản lí dữ liệu.- Dễ phát triển ứng dụng và ngời sử dụng.Có nhiều phơng pháp phân tán dữ liệu trong môi trờng phân tán. một số phơng pháp đơn giản, một số phơng pháp phức tạp hơn. điều quan trọng trọng trong DDM là phơng pháp phân tán dữ liệu sẽ ảnh hởng rất lớn đến đến cách truy nhập dữ liệu.Các phơng pháp phân tán dữ liệu đợc mô tả trong chơng này đợc áp dụng cho nhiều mô hình dữ liệu khác nhau: phân cấp, mạng, tuần tự hay quan hệ. Tuy nhiên mô hình quan hệ sẽ đợc sử dụng để minh hoạ.1.1. mô hình dữ liệu quan hệ- bảng- cột- dòng- khoá chính- khoá ngoài- chuẩn hoá dữ liệuxét thí dụ về sở dữ liệu ngân hàng (h.10.1)1.2. rút trích thủ côngtrong môi trờng phân tán, dữ liệu phân tán tại nhiều vị trí. Tuy nhiên, về logic, dữ liệu phân tán còn thuộc về một kho dữ liệu hợp nhất tập trung. ngời thiết kế môi tr-ờng DDM phải quyết định :- dữ liệu sẽ đợc lấy nh thế nào và khi nào từ kho tập trung - vị trí tối u cho việc đặt các phần tử dữ liệu là gì?câu hỏi sau liên quan đến các phơng pháp truy nhập dữ liệu khác nhau cũng nh các đặc tính của mạng. Câu hỏi trớc không liên quan vị trí dữ liệu và nó đợc nghiên cứu trong chơng này.một trong những cách đơn giản nhất để phân tán dữ liệu là cho phép ngời sử dụng copy thủ công dữ liệu từ một vị trí tập trung đến các vị trí khác. phơng pháp phân tán dữ liệu này đợc gọi là rút trích thủ công. Nó đợc ngời sử dụng điều khiển khá đơn giản.thí dụ nh ứng dụng bank hình 10.2 kho dữ liệu trung tâm đợc đặt ở New york và chứa dữ liệu về khách hàng, kiểm tra và tài khoản tiết kiệm trong các bảng tơng ứng. Ngoài ra nó còn bảng tỷ giá hiện thời. Trong môi trờng phân tán, các chi nhánh Bank duy trì các kho tài khoản và khách hàng ứng với khách hàng của họ (h.10.2). nếu 1 chi nhánh mới mở ra, ngời quản lí thể copy đầy đủ hay một phần của bảng tỷ giá và nạp xuống bảng tỷ giá của chi nhánh mới.Một hoạt động nh vậy thể đợc thực hiện bằng rút trích thủ công. Nó thể làm theo 2 cách:- từ site trung tâm- từ chi nhánh mớitrong trờng hợp mô hình sở dữ liệu quan hệ, việc rút trích và nạp thể đợc thực hiện bằng các mệnh đề SQL nh Select, inserttuy nhiên, rút trích thủ công chỉ thể làm đợc bằng một nhóm hạn chế các mệnh đề SQL với 1 điểm dữ liệu đơn (site trung tâm hay chi nhánh mới), thực tế, rút trích thủ công thể thực hiện bằng các kiểu yêu cầu từ xa hay giao dịch từ xa của truy nhập dữ liệu phân tán (sẽ đợc trình bày trong 10.2)1.3. bắn tự độngđể tự động rút trích thủ công, ngời ta đa các nhiệm vụ phân tán dữ liệu vào hệ quản trị cơ sở dữ liệu phân tán. khi các yêu cầu về phân tán dữ liệu tăng lên nhiều và phức tạp thì các hệ quản trị cơ sở dữ liệu phân tán sẽ làm nhiệm vụ bắn tự động một cách đơn giản. tởng tợng rằng, các hệ quản trị sở dữ liệu cung cấp khả năng định nghĩa bắn tự động 1 bản copy của 1 bảng đến 1 vị trí cần thiết cũng nh tần suất của thủ tục nạp-rút trích. Trong SQL định nghĩa nh vậy thể nh:CREATE SNAPSHORT <NAME> ASSELECT FROM TIME <HH:MM:SS>INTERVAL <HH:MM:SS> Trong xử lí SnapShort, ngời sử dụng thể xác định các bảng, cột nào thể đợc sử dụng để tạo SnapShort, thời điểm và tần xuất xử lí SnapShort thể đợc xác định (thí dụ vào lúc nửa đêm, hay từng tiếng một). Sau đó hệ quản trị sở dữ liệu sẽ tự động thực hiện các hành động cần thiết.Thế mạnh. SnapShort đợc thiết kế cho các thông tin khá tĩnh phân tán mà sự sự thay đổi không thờng xuyên. thí dụ bảng tỷ giá là hay dung SnapShort vì các thay đổi tỷ giá đợc làm 1 lần trong 1 ngày.Hạn chế. Do làm tự động nên SnapShort đặc biệt hạn chế khi truy nhập dữ liệu là chỉ đọc.1.4. bản saovới những ứng dụng mà dữ liệu phân tán thể đợc cập nhật ở nhiều vị trí, xử lí SnapShort sẽ không thích hợp. 1 ứng dụng nh vậy thể yêu cầu rằng: bản sao của cùng 1 bảng thể đợc duy trì ở nhiều vị trí khác nhau. DDBMS khả năng hỗ trợ 1 phơng pháp phân tán dữ liệu tăng cờng bản sao:- tạo và duy trì các bản sao của 1 bảng đã cho tại nhiều vị trí yêu cầu.- Duy trì tính bền vững dữ liệu qua các bản sao (hoặc là xử lí đồng bộ/dị bộ).Trong thí dụ về ứng dụng Bank, giả sử rằng các khách hàng thể chuyển account của mình từ chi nhánh này đến chi nhánh khác. nếu bản ghi khách hàng và các thông tin tài khoản liên quan không tìm thấy trong chi nhánh chuyển đến thì các thông tin yêu cầu thể đợc copy từ chi nhánh cũ. Trờng hợp mở rộng: toàn bộ bảng CUSTOMER thể đợc sao với các bản sao đợc đặt ở các chi nhánh. để duy trì các bản ghi đúng, các bản sao phải chắc chắn các thông tin về khách hàng và các tài khoản của họ giống nhau.đồng bộ hoá các cập nhật giữa các bản sao không phải chỉ là vấn đề mà hệ quản trị sở dữ liệu phân tán phải giải quyết. Khi nhiều bản copy của 1 bảng tồn tại, các ứng dụng truy nhập đến dữ liệu sao trong môi trờng phân tán sẽ không nhận biết đợc vị trí của bản sao. Mặt khác, các ứng dụng phải đợc thay đổi theo vị trí của hệ thống chứa nó và theo số các bản sao cần đợc duy trì hiện tại. Thật vậy, nếu mỗi chi nhánh của bank duy trì 1 chơng trình bảng cân đối khách hàng thì ch-ơng trình sẽ không nhận biết đợc vị trí của bản sao bảng khách hàng mà nó truy nhập.Bên cạnh việc sao bảng, các yêu cầu dữ liệu phân tán, tái tạo bảng thể bao gồm cả việc sao cấp dòng, mà chỉ những dòng riêng lẻ nào đó của bảng đã cho cần DDBMS sao chép. Nếu chỉ các dòng đợc cập nhật là đợc sao chép thì sao chép mức độ dòng thể là đồng bộ dữ liệu đơn giản.Trong sao chép, tính bền vững dữ liệu và trong suốt vị trí là những nhiệm vụ mà DDBMS sẽ phải thực hiện để thể hỗ trợ dữ liệu sao chép phân tán. mỗi yêu cầu này đều là 1 vấn đề lớn về mặt thiết kế và thể hiện.1.5. phân mảnh sao chép dữ liệu vẻ nh khá khó thực hiện, ngay cả khi làm với toàn bộ các bảng. Nó thể hiệu quả hơn nếu sao chép chỉ một phần (mảnh của dữ liệu . phân mảnh dữ liệu tuy vậy lại là phơng pháp phức tạp nhất của phân tán dữ liệu.Phân mảnh dữ liệu đợc minh hoạ tốt nhất trong mô hình quan hệ, ở đó các bảng dữ liệu thể bị phân mảnh theo chiều dọc/ngang.để minh hoạ phân mảnh dữ liệu ngang, ta mở rộng ứng dụng bank bằng cách thêm bảng Employee, mỗi dòng là 1 ngời (h.10.3). trong một môi trờng phân tán, bảng Employee đợc phân tán đến các chi nhánh khác nhau dựa vào danh sách nhân công của từng chi nhánh. để làm điều này, toàn bộ bảng Employee đợc phân mảnh theo chiều ngang bằng cách tạo ra các tập con của các nhân viên các dòng trong bảng Employee. Thí dụ khác là trong bảng Players, lấy các VĐV ở các thành phố khác nhau.để phân mảnh theo chiều dọc, ta giả sử rằng bảng Employee chứa các cột ghi tình hình sử dụng thuốc của mối ngời, nó chỉ đợc đặt ở phòng ytế để theo dõi tập trung. Nên phân tán các cột này đến các phòng ytế đợc gọi là phân mảnh theo chiều dọc và đợc đặt ở vị trí thích hợp (h10.4). tất nhiên thể phân mảnh cả ngang lẫn dọc để đợc tập con các dòng và cột. không để ý đến phơng pháp phân mảnh dữ liệu, thể dễ lựa chọn hơn là để dữ liệu cần thiết gần nơi sử dụng nhất (về mặt vật lí).Tuy nhiên, nhợc điểm chính của phân mảnh là thực hiện phức tạp, rất khó làm trong suốt việc truy nhập dữ liệu trong môi trờng phân tán. xét bảng Employee, nếu bị phân mảnh (dọc/ngang/cả 2) thì nếu 1 ứng dụng quản lí đòi hỏi toàn bộ các bản ghi của các nhân viên thì nó phải truy nhập đến dữ liệu nhân viên ở mọi chi nhánh, sau đó kết hợp lại với dữ liệu của các nhân viên ở phòng ytế. Các nhân viên thể chuyển từ chi nhánh này đến chi nhánh khác, và các chi nhánh thể phát triển to hơn ứng dụng cần truy nhập dữ liệu phân tán sẽ phải hoàn toàn trong suốt về vị trí dữ liệu và phơng pháp phân mảnh. Giải pháp: điều này thể đạt đ-ợc bằng cách làm khung nhìn dữ liệu phân mảnh và sử dụng nó nh một bảng đơn. (thay vì phải viết lại ứng dụng mỗi khi một nhân viên đợc truyền.Cung cấp nhận biết dữ liệu đang nằm trong một bảng đơn ở 1 vị trí đơn (trong suốt vị trí và phân mảnh) là 1 thách thức lớn đối với ngời thiết kế các DDBMS.1.6. phân tích phân tán dữ liệu những ngời thiết kế môi trờng phân tán phải quyết định những tài nguyên tính toán nào phải phân tán cũng nh chúng nằm ở đâu. các quyết định về khu trú dữ liệu nằm trong các yêu cầu thực hiện một phân tán thực sự. nhiều phơng pháp để phân tích phân tán dữ liệu.Một trong những phơng pháp đơn giản và khá tin cậy thờng đợc sử dụng để thực hiện một phân tích đặt dữ liệu phân tán là dựa vào việc mô phỏng các tơng tác trong một môi trờng phân tán. xét thí dụ sau. Giả sử thí dụ ứng dụng bank chỉ 2 vị trí. Site trung tâm đặt ở s1, và 1 chi nhánh đặt ở b1. Giả sử rằng bảng customer đợc giữ toàn bộ ở trung tâm, đợc sao 1 phần /dọc hay ngang/ đặt ở chi nhánh b1. để duy trì thông tin khách hàng vững chắc, mỗi cập nhật ở một vị trí nào cũng đều đợc làm ở vị trí kia, trong khi các thao tác chỉ xem thể đợc thực hiện 1 cách cục bộ.Giả sử rằng bảng customer ở s1 10.000 bản ghi, đợc đọc 2000 lần và cập nhật 500 lần/ngày. bảng customer ở b1 1000 bản ghi và đợc đọc 1000 lần và đợc cập nhật 100 lần/ngày./xem hình 10.5/ Nếu toàn bộ dữ liệu khách hàng đợc đặt ở 1 vị trí nào đó, thì truy nhập dữ liệu từ vị trí khác phải đợc gửi qua mạng nối các vị trí này. nếu dữ liệu toàn bộ khách hàng đặt ở s1 thì lu thông dữ liệu từ/đến chi nhánh b1 sẽ là 1100 thông báo (1000 đọc và 100 cập nhật). Ngợc lại, nếu dữ liệu toàn bộ khách hàng đặt ở b1 thì tổng số lu thông mạng sẽ là 2500 thông báo (2000 đọc và 500 cập nhật). điều này đặt dữ liệu khách hàng ở site trung tâm sẽ là tốt hơn. tuy nhiên dễ chứng minh rằng phân tán dữ liệu thể làm cho lu thông mạng tốt hơn. xét các ma trận các vị trí dữ liệu thể với số liệu lu thông kết quả (h.10.5 dới). Nhớ rằng các kết quả lu thông từ dữ liệu đọc không thấy ở vị trí đã cho Với 3 cấu hình thể thì cấu hình thứ 3 theo quan điểm lu thông mạng là tối u (lu thông 600 thông báo 500 cho cập nhật từ s1+ 100 cho cập nhật từ b1)Tuy không phải là hoàn toàn chính xác, 1 phân tích nh vậy thể đợc mở rộng để bao gồm những đối tợng dữ liệu tích (thí dụ bảng saving account và bảng checking account), giá/giao dịch (đặc biệt nếu sự lựa chọn mạng), giá và các yêu cầu về lu trữ dữ liệu, và các đặc điểm khác của sự phân tán dữ liệu.Các kết luận quan trọng của tiếp cận phân tích là:- không để ý đến phơng pháp phân tán dữ liệu thì phân tán dữ liệu lợi cho l-u chuyển hệ thống phân tán.- vị trí của dữ liệu thể đợc quyết định dựa vào dữ liệu hợp lí, các mô hình xử lí (đọc, cập nhật), số lợng và các đặc trng của vị trí dữ liệu thể.2. truy nhập dữ liệu phân tánkhi dữ liệu bị phân tán ở nhiều vị trí, toàn bộ/một phần của logic quản lí dữ liệu cũng phải đợc phân tán đồng hành cùng dữ liệu. Nh đã thảo luận, ít nhất một số phần của logic xử lí sở dữ liệu (hệ quản trị sở dữ liệu) phải nằm trên cùng hệ thống với sở dữ liệu của nó.Không cần để ý đến những phơng pháp phân tán dữ liệu nào đợc thực hiện, việc truy nhập dữ liệu đợc hệ quản trị cơ sở dữ liệu phân tán cung cấp phải đợc thực hiện theo cách sao cho vị trí của dữ liệu phải trong suốt đối với ngời sử dụng và các ứng dụng: trong môi trờng 1 sở dữ liệu đợc phân tán thực sự, ngời sử dụng và các ứng dụng sẽ lhông biết rằng dữ liệu đợc phân tán.Trong truy nhập cơ sở dữ liệu phân tán, yêu cầu dữ liệu đợc phân tán ở bất kì đâu trong các nút mạng là không chỉ phù hợp mà còn tuyệt đối cần trong các kiến trúc khách hàng/ dịch vụ hỗ trợ phân tán dữ liệu giữa các Client vàServer. bất kì thể hiện khách hàng/ dịch vụ cho phép dữ liệu (và 1 hệ quản trị sở dữ liệu địa ph-ơng ) đợc duy trì trên các hệ thống khách cũng nh trên Server sở dữ liệu phải đ- ợc cung cấp cách truy nhập dữ liệu phân tán. vì vậy các kiểu truy nhập dữ liệu phân tán khác nhau trong kiến trúc khách hàng/ dịch vụ trong đó 1 ứng dụng đặt trên trạm và đa ra các yêu cầu dữ liệu địa phơng (nằm ở Client ) hay dữ liệu từ xa (nằm trên Server). các kiểu truy nhập dữ liệu phân tán sẽ đợc mô tả dới đây và CSDLQH đợc sử dụng để minh hoạ. Chú ý rằng 1 số giải pháp quản lí dữ liệu phân tán đợc C.J.Date 1 trong những ngời thiết kế csdlqh đầu tiên - phát biểu . 12 quy tắc của C.J.Date đợc liệt kê trong phụ lục D và đợc thảo luận kỹ trong chơng 11.10.2.1. yêu cầu từ xaxét một môi trờng 1 Client và 1 Server đơn giản. 1 trong những nhiệm vụ đơn giản nhất mà ứng dụng khách thể đa ra là 1 yêu cầu dữ liệu đến Server. khi 1 ứng dụng đa ra 1 yêu cầu dữ liệu đơn để đợc xử lí ở 1 site từ xa đơn thì nó đợc gọi là yêu cầu từ xa (h.10.6). trong trờng hợp mô hình quan hệ, 1 yêu cầu đơn giản nh vậy là 1 mệnh đề SQL đơn nhằm vào 1 site (Server ) từ xa đơn. trong thí dụ ứng dụng bank, nếu bảng Customers nằm tập trung trên S1 chứ không phân tán thì chi nhánh B1 (từ xa) thể đa ra 1 yêu cầu SQL từ xa để đọc các thông tin của khách hàng. 1 yêu cầu nh vậy chỉ chứa 1 tham khảo đến chỉ 1 dữ liệu từ xa. 1 DDBMS thể hỗ trợ các yêu cầu từ xa 1 cách trong suốt nếu DDBMS duy trì các vị trí dữ liệu. Ngợc lại, DDBMS thể hỗ trợ các yêu cầu từ xa nếu ứng dụng xác định các vị trí dữ liệu.Trong trờng hợp hqtcsdlqh phân tán, 1 SQL từ xa yêu cầu truy nhập dữ liệu khách hàng ở New York từ bảng Customers trong sở dữ liệu bankDB nằm ở S1 thể làm nh sau:SELECT *FROM Server1.BANKDB.CUSTOMERS S1ClientWHERE S1C.SITY=NEW YORKCác yêu cầu từ xa thể đợc sử dụng để thực hiện phơng pháp rút trích thủ công để phân tán dữ liệu. Trong kịch bản này, khi bảng Customers đợc phân tán thủ công đến các chi nhánh thể đa ra 1 yêu cầu từ xa cho các dữ liệu khách hàng và sau đó thể copy dữ liệu đó vào sở dữ liệu địa phơng.10.2.2. giao dịch từ xa 1 yêu cầu từ xa cũng thể định nghĩa trên quan điểm giao dịch và các đơn vị logic công việc.định nghĩa. 1 yêu cầu từ xa thể định nghĩa lại nh là một giao dịch xử lí dữ liệu hay 1 đơn vị logic công việc chứa yêu cầu dữ liệu đơn nhằm vào dữ liệu nằm ở vị trí từ xa đơn (Server). bằng cách định nghĩa một LUW, khi 1 yêu cầu từ xa đợc thực hiện xong, dữ liệu từ xa ở trong 1 trạng thái mới, chắc chắn, và toàn bộ công việc đợc làm trong 1 yêu cầu từ xa đợc xác nhận. 1 khả năng của giao dịch từ xa là cho phép 1 giao dịch chứa nhiều yêu cầu dữ liệu nhng tất cả các dữ liệu này đều nằm ở 1 vị trí đơn từ xa (h.10.7.). nếu 1 yêu cầu từ xa tái hiện 1 LUW hành động đơn, đơn giản thì 1 giao dịch từ xa thể gồm nhiều hành động nhng tất cả đều nhằm đến dữ liệu nằm ở 1 vị trí đơn, từ xa và các hành động này đều đợc gộp trong 1 LUW đơn. vì thế, nhiều khi 1 giao dịch từ xa đợc gọi là 1 đơn vị công việc từ xa (RUW). Trong kiến trúc khách hàng/ dịch vụ , giao dịch từ xa nhằm vào dữ liệu từ xa đợc nằm ở Server đơn và đợc phát động từ 1 máy khách trong 1 LUW đơn. trong trờng hợp mô hình dữ liệu quan hệ, 1 giao dịch từ xa thể chứa nhiều mệnh đề SQL, nhng tất cả đều nhằm đến các dữ liệu nằm ở cùng 1 site đơn từ xa (1 Server) .trong thí dụ về ứng dụng bank, yêu cầu từ xa để đọc thông tin khách hàng trong bảng Customers từ bất kì chi nhánh nào thể mở rộng bằng cách thêm 1 hành động UPDATE. Thí dụ, 1 chi nhánh từ xa B1 (Server B1) không chỉ cần các thông tin về khách hàng NEW YORK mà còn cần cập nhật POSTED INDICATOR của bảng chi nhánh (cả 2 bảng đều nằm trên S1). Cả 2 hoạt động này tái hiện 1 giao dịch từ xa phải đợc thực hiện nh 1 LUW. Nếu ứng dụng đợc yêu cầu xác định các vị trí dữ liệu bằng cách sử dụng các tên bảng đợc kiểm tra đầy đủ thì 1 giao dịch nh vậy thể là:BEGIN WORKSELECT *FROM Server1.BANKDB.CUSTOMERS S1CWHERE S1C.SITY=NEW YORKUPDATE Server1.BANKDB.BRANCHSET POSTED_IND=YESCOMMIT WORKChú ý rằng 2 mệnh đề SELECT và UPDATE đều đợc bao bằng 1 gói LUW (bắt đầu và kết thúc là BEGIN, COMMIT). Vì vậy, đơn vị công việc từ xa đợc minh hoạ ở đây sẽ chỉ thành công nếu cả 2 mệnh đề SQL là thành công. Các giao dịch từ xa của ngời sử dụng cũng thể đợc sử dụng để thực hiện phơng pháp rút trích thủ công của phân tán dữ liệu.10.2.3. giao dịch phân tán khả năng giao dịch phân tán cho phép 1 giao dịch chứa nhiều yêu cầu dữ liệu đến các dữ liệu ở nhiều vị trí. Mỗi yêu cầu nhằm đến dữ liệu nằm ở 1 vị trí đơn (từ xa), mà dữ liệu ở mỗi yêu cầu thể nằm ở những vị trí khác nhau (h.10.8). một giao dịch phân tán cho phép truy nhập đến nhiều vị trí trong một LUW đơn.trong kiến trúc khách hàng/ dịch vụ, 1 giao dịch phân tán thể truy nhập đến dữ liệu phân tán trên nhiều Server từ 1 trạm trong 1 LUW đơn. 1 giao dịch phân tán thể hiện 1 đơn vị công việc phân tán (DUW). Trong mô hình dữ liệu quan hệ, 1 giao dịch phân tán thể chứa nhiều mệnh đề SQL, mỗi mệnh đề yêu cầu 1 dữ liệu1 vị trí Server thể.Trong ứng dụng bank, văn phòng trung tâm thể cần thông tin về các nhân viên trình độ giáo dục bậc M.B.A làm ở chi nhánh B1, đồng thời cũng cần lịch sử thuốc của các nhân viên của chi nhánh này. các bản ghi thuốc đợc giữ ở phòng ytế (Server M). cả 2 hành động này thể hiện 1 giao dịch phân tán vì chúng nhằm vào nhiều vị trí dữ liệu trong cùng một LUW. Chúng thể là:BEGIN WORKSELECT * FROM Server1.BANKDB.EMPLOYEE S1CWHERE S1C.EDULEVEL=MBASELECT *FROM ServerM.BANKDB.EMPL_MEDWHERE ServerM.BANKDB.EMPL_MED.BRANCH=B1COMMIT WORKChú ý rằng, mặc 2 mệnh đề SQL nhằm vào các vị trí dữ liệu khác nhau, nhng chúng bị bao trong 1 LUW (begin .commit), vì thế đơn vị công việc phân tán ở đây sẽ thành công chỉ nếu cả 2 mệnh đề SQL đều thành công. Nếu 1 trong 2 mệnh đề thất bại thì toàn bộ LUW thất bại.10.2.4. yêu cầu phân tán.yêu cầu phân tán là phơng pháp truy nhập dữ liệu phân tán phức tạp nhất. Một yêu cầu phân tán gồm một hay nhiều yêu cầu dữ liệu, mỗi yêu cầu dữ liệu này thể truy nhập dữ liệu ở nhiều vị trí và vì thế thể đợc xử lí ở nhiều vị trí khác nhau. Các hoạt động đợc thực hiện trong một yêu cầu phân tán đợc gói trong một LUW đơn.trong kiến trúc khách hàng/ dịch vụ, do khả năng của yêu cầu phân tán dẫn đến thể phân tán dữ liệu ở nhiều Server hay những bản sao hoặc phân mảnh và thể đợc truy nhập một cách trong suốt từ 1 máy trạm Client trong 1 LUW đơn (h.10.9).trong trờng hợp mô hình dữ liệu quan hệ, 1 yêu cầu phân tán thể chứa nhiều mệnh đề SQL, mỗi mệnh đề tham khảo đến dữ liệu nằm ở nhiều Server.thí dụ. Trong ứng dụng bank, văn phòng trung tâm (S1) cần báo cáo các nhân viên trình độ MBA đang làm việc ở chi nhánh B1 (Server B1), và cả tình hình sử dụng thuốc của họ (giữ ở Server M). hơn nữa, bảng Branch cho chi nhánh B1 giữ ở S1 phải đợc cập nhật để chỉ thị rằng báo cáo đợc hoàn thành. Một yêu cầu công tác nh vậy thể làm bằng cách:1/ nhập 2 bảng : EMPLOYEE ở B1 và EMPL_MED ở Server M.2/ cập nhật bảng BRANCH ở S1.Yêu cầu phân tán nh vậy thể làm : Chú ý rằng :- mệnh đề SQL đầu nhập 2 bảng ở 2 vị trí khác nhau, trong khi mệnh đề sau lại cập nhật dữ liệu ở vị trí khác.- các hoạt động này đợc thực hiện nh 1 LUW, mặc nhiều hệ quản trị sở dữ liệu (vật lí) ở nhiều nơi cùng tham gia. Cả 4 kiểu truy nhập dữ liệu phân tán đợc hỗ trợ bởi các hệ quản trị cơ sở dữ liệu phân tán. nhng chỉ xử lí yêu cầu phân tán mới thể hiện hết khả năng của 1 hệ quản trị sở dữ liệu phân tán.10.3. quản lí giao dịch sở dữ liệu.quản lí giao tiếp sở dữ liệu D . dữ liệu nh thế nào? tích hợp dữ liệu? Tính vững chắc dữ liệu ? sẽ đ ợc làm rõ trong chơng này .1. các phơng pháp phân tán dữ liệuDDM xét dữ liệu (cơ sở. khoá ngoài- chuẩn hoá dữ liệuxét thí dụ về cơ sở dữ liệu ngân hàng (h .10 .1) 1.2. rút trích thủ côngtrong môi trờng phân tán, dữ liệu phân tán tại nhiều vị trí.

Ngày đăng: 13/11/2012, 10:31

Từ khóa liên quan

Tài liệu cùng người dùng

Tài liệu liên quan