intTypePromotion=1
zunia.vn Tuyển sinh 2024 dành cho Gen-Z zunia.vn zunia.vn
ADSENSE
 » 
 » 

Cơ sở dữ liệu - bài 9

Chia sẻ: Chu Văn Thắng Doremon | Ngày: | Loại File: PDF | Số trang:0

Thêm vào BST
Báo xấu
106
lượt xem 9
download
 
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Trong bài này, chúng ta sẽ chú ý đến vấn đề bảo vệ dữ liệu, nghĩa là bảo vệ cơ sở dữ liệu chống lại các nguy cơ tiềm ẩn...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Cơ sở dữ liệu - bài 9

  1. Cơ sở dữ liệu ThS. Lê Văn Lợi B ài 9 – Bảo vệ dữ liệu Trong bài này, chúng ta sẽ chú ý đến vấn đề bảo vệ dữ liệu, nghĩa là bảo vệ cơ sở dữ liệu chống lại các nguy cơ tiềm ẩn (cố ý hoặc vô tình) làm cho dữ liệu bị hỏng hoặc bị mất. Trong thực tế, có rất nhiều rủi ro và nguy cơ có thể xảy ra: − Chương trình hệ thống đang chạy bị treo ở gữa chừng, làm cho CSDL ở vào một trạng thái bất định. − Hai chương trình cùng chạy đồng thời, tranh chấp hoặc can thiệp vào cùng một khối dữ liệu làm cho kết quả bị sai đi. − Dữ liệu nhạy cảm bị lộ hoặc bị sửa đổi bởi người dùng không có quyền, không được phép. − Các phép toán trên CSDL làm cho CSDL bị thay đổi và ở một trạng thái không toàn vẹn, làm cho các ràng buộc trong CSDL bị phá vỡ. Và còn nhiều các nguy cơ khác nữa. Từ đó, HQT CSDL phải cung cấp nhiều bộ công cụ để khống chế và giảm thiểu các nguy cơ nêu trên. Các vấn đề lần lượt được đề cập trong bài này sẽ là: Phục hồi dữ liệu, Xử lý tranh chấp, An toàn dữ liệu và Đảm bảo tính toàn vẹn. 1./ Phục hồi dữ liệu Phục hồi dữ liệu, theo nghĩa của CSDL là CSDL tự phục hồi về một trạng thái ổn định sau khi gặp lỗi hoặc khi toàn bộ CSDL gặp phải sự cố, làm cho CSDL không còn đúng nữa. Để thực hiện được việc này, k ỹ thuật sơ đẳng được áp dụng là redundancy – nghĩa là tạo dữ liệu dư thừa, trùng lặp. Nói theo một cách khác là mỗi một mẫu thông tin được tạo ra, sẽ có ít nhất là 2 nơi cất giữ: nơi lưu chính và nơi lưu dự phòng. Nơi cất giữ dự phòng khác với nơi cất giữ chính, thường được ẩn đi, người dùng không biết. Chủ đề về phục hồi dữ liệu là chủ về phục hồi dữ liệu chung cho bất cứ mô hình cơ sở dữ liệu nào, có thể ứng dụng được cho mô hình CSDL quan hệ. 1.1.- Giao dịch (transaction) Một giao dịch có thể được hiểu là một công đoạn logic không tách rời. Công đoạn này hoặc là thực hiện trọn vẹn, hoặc là không làm gì cả, không có trường hợp làm dở dang. Hãy lấy một ví dụ. Giả thiết là trong bảng part, ta thêm một trường có tên là totqty, là tổng số lượng phụ tùng đã chuyển đến từ các nhà cung cấp, tính theo mã phụ tùng. Giả thiết là nhà cung cấp S5 cấp 1000 phụ tùng P1. Bai-9.doc *** Trang 1
  2. Cơ sở dữ liệu ThS. Lê Văn Lợi Để thực hiện “giao dịch” này, về mặt logic, chúng ta sẽ làm hai việc nhỏ, đó là: 1. Chèn thêm vào bảng sp các giá trị S5, P1, 1000; 2. Cộng thêm 1000 vào vào thuộc tính totqty của bản ghi có khóa là P1 trong bảng part. Ta hãy xem đoạn mã giả lập sau đây: START TRANSACTION; INSERT INTO sp (s_id, p_id, qty) VALUES ('S5', 'P1', 1000); IF any error occurred THEN GO TO UNDO; UPDATE part SET totqty = totqty+1000 WHERE p_id = 'P1'; IF any error occurred THEN GO TO UNDO; COMMIT; GO TO FINISH; UNDO: ROLLBACK; FINISH: RETURN; Ý nghĩa của đoạn mã trên là: Bắt đầu Chèn các giá trị S5, P1, 1000 vào bảng sp; Nếu chèn gặp lỗi, hãy nhảy đến nhãn UNDO; Cập nhật trường totqty bằng cách cộng thêm 1000 vào giá trị của trường này, chỉ thực hiện đối với bản ghi có khóa là P1. Nếu cập nhật gặp lỗi, hãy nhảy đến nhãn UNDO Thực hiện tất cả các thao tác trên tình từ lệnh bắt đầu Nhảy đến nhãn FINISH UNDO: Hủy các thao tác kể từ lệnh bắt đầu; FINISH: Kết thúc Vấn đề của ví dụ trên là: − Nếu đã thực hiện thì phải thực hiện đồng thời chèn và cập nhật; − Nếu một trong 2 thao tác này không thành công thì phải hủy bỏ toàn bộ; Một công đoạn như trên được gọi là một giao dịch. Nghĩa là một giao dịch luôn đảm bảo chuyển CSDL từ trạng thái ổn định này sang môt trạng thái ổn định Bai-9.doc *** Trang 2
  3. Cơ sở dữ liệu ThS. Lê Văn Lợi khác. Từ ổn định ở đây được hiểu là CSDL luôn luôn đảm bảo các ràng buộc đã được đề ra không bị phá vỡ. Chúng ta hãy tưởng tượng là nếu chỉ một trong 2 thao tác được thực hiện thì CSDL sẽ bị lỗi như thế nào. Đặc điểm của giao dịch là tính nguyên tử của nó – nó phải được thực thi giống như chỉ một lệnh vậy. Để đảm bảo tính nguyên tử của nó, cấu trúc của một giao dịch thường bao gồm các từ khóa sau: START TRANSACTION | BEGIN COMMIT ROLLBACK − Để bắt đầu thực hiện một giao dịch, chúng ta sử dụng lệnh START TRANSACTION hoặc lệnh BEGIN. − Sau khi thực hiện các thao tác không gặp lỗi nào, ta gọi lệnh COMMIT. − Nếu trong quá trình thực hiện các thao tác, ta gặp một lỗi nào đó, ta gọi lệnh ROLLBACK. Như vậy, chỉ sau khi có lệnh COMMIT các thay đổi mới thực sự diễn ra. Trước thời điểm đó, các thay đổi chỉ mang tính chất tạm thời. Khi có lệnh ROLLBACK, các thay đổi kể từ lệnh START TRANSACTION đều bị hủy bỏ. Có thể chúng ta sẽ tò mò về mặt kỹ thuật, làm thế nào để thực hiện được lệnh ROLLBACK. Thông thường, người ta sử dụng một sổ nhật ký lệnh, ghi lại tất cả các giá trị trước và sau một lệnh. Nhờ đó, khi cần quay trở lại, người ta lần ngược sổ nhật ký và cho phục hồi các giá trị trước đó. Cần nói thêm rằng, các lệnh SQL đều phải là các giao dịch, nghĩa là phải đảm bảo tính nguyên tử - hoặc thực hiện thì thực hiện trọn vẹn, còn nếu không thì không thực hiện gì cả. 1.2.- Các thuộc tính ACID của một giao dịch ACID là viết tắt của các từ Atomicity, Consistency, Isolation và Durability. Atomicity (Tính nguyên tử): Tính trọn vẹn của xử lý: làm trọn vẹn hoặc không làm gì cả. Consistency (Tính nhất quán): Khi thực hiện các giao dịch, phải đảm bảo CSDL luôn luôn ở trạng thái ổn định – nghĩa là các ràng buộc không bị phá vỡ. Bai-9.doc *** Trang 3
  4. Cơ sở dữ liệu ThS. Lê Văn Lợi Isolation (Tính biệt lập): các giao dịch biệt lập với nhau, không chồng chéo lên nhau. Đây có một phần trách nhiệm của người lập trình, phải đảm bảo rằng các giao dịch không xen nhau. Nói một cách khác, giả thiết ta có 2 giao dịch là T1 và T2 thì T1 có thể được COMMIT trước hoặc T2 có thể COMMIT trước nhưng không được phép T1 và T2 COMMIT đồng thời. Durability (Tính bền vững): Khi một giao dịch đã thực hiện COMMIT, thì các cập nhật sẽ được giữ nguyên, mặc dù ngay sau đó hệ thống có thể bị treo. 2./ Xử lý tranh chấp Tranh chấp (concurrency) và phục hồi dữ liệu có mối liên kết mật thiết với nhau. Tranh chấp xảy ra khi có nhiều giao dịch cùng truy cập đồng thời vào cùng một tập hợp dữ liệu. Trong trường hợp này, HQT CSDL phải có cơ chế đảm bảo và kiểm soát được các giao dịch không can thiệp lẫn nhau, làm hỏng dữ liệu của nhau. 2.1.- Ba vấ n đề tranh chấp Người ta nhận thấy có 3 vấn đề chính trong tranh chấp có thể làm cho các giao dịch bị sai đi. Và từ đó cần tìm ra cơ chế để giải quyết các vấn đề đã đặt ra. Các vấn đề đó là: 2.1.1 Vấn đề cập nhật mất hiệu lực (lost update problem) Giả sử giao dịch A và giao dịch B diễn biến như trong hình vẽ sau, theo thứ tự thời gian và cùng tác động lên bản ghi p. Giao dịch A Giao dịch B T - - - - - - Lấy giá trị p - t1 Lấy giá trị p - t2 Sửa đổi giá trị p - t3 Sửa đổi giá trị p - t4 ↓ - Giao dịch A lấy giá trị p vào thời điểm t1. Giao dịch B cũng lấy giá trị đó vào thời điểm t2. Giao dịch A sửa đổi giá trị của p vào thời điểm t3. Giao dịch B sửa đổi giá trị của p vào thời điểm t4. Các sửa đổi của giao dịch A đã bị mất vì giao dịch B đã ghi đè lên. Bai-9.doc *** Trang 4
  5. Cơ sở dữ liệu ThS. Lê Văn Lợi 2.1.2 Vấn đề tính phụ thuộc giao dịch chưa xử lý (uncommitted dependency problem) Vấn đề này xả y ra khi một giao dịch trích xuất (hoặc cập nhật) một bản ghi mà bản ghi đó được cập nhật bởi một giao dịch khác mà giao dịch khác này chưa được xử lý (COMMIT hoặc ROLLBACK). Xem tình huống này trong hình vẽ sau: Giao dịch A Giao dịch B T - - - Cập nhật p - t1 Lấy giá trị p - - - - t2 ROLLBACK t3 ↓ - Giao dịch A Giao dịch B T - - - Cập nhật p - t1 Cập nhật p - - - - t2 ROLLBACK t3 ↓ - Như trong hình vẽ, giao dịch A hoặc nhận được một giá trị không tồn tại hoặc cập nhật một giá trị mà đã bị giao dịch B ROLLBACK. Bai-9.doc *** Trang 5
  6. Cơ sở dữ liệu ThS. Lê Văn Lợi 2.1.3 Vấn đề phép toán gộp không nh ất quán (inconsistent analysis problem) TK1 TK2 TK3 40 50 30 Giao dịch A Giao dịch B T - - - - - Lấy GT TK 1 - t1 sum = 40 Cộng thêm GT TK2 - t2 sum = 90 Lấy GT TK 3 t3 Cập nhật TK 3 t4 30 → 20 Lấy GT TK 1 t5 - Cập nhật TK 1 t6 40 → 50 - COMMIT t7 Cộng thêm GT TK 3 t8 sum = 110 (Đúng: phải là 120) ↓ - Trong hình vẽ trên, giao dịch A làm phép toán cộng giá trị các tài khoản, còn giao dịch B chuyển giá trị 10 từ tài khoản 3 vào tài khoản 1. Rõ ràng, kết quả phép cộng không đúng, vì giao dịch B chỉ chuyển giá trị trong nội bộ các tài khoản 1, 2 và 3. 2.2.- Khóa dữ liệu (locking) Để giải quyết vấn đề tranh chấp, người ta thường sử dụng một kỹ thuật có tên gọi là locking – khóa dữ liệu. Ý tưởng rất đơn giản: khi một giao dịch nào đó muốn một phần nào đó của CSDL không bị thay đổi một cách không lường trước được, giao dịch đó yêu cầu nhận một khóa (lock). Chẳng hạn, khi giao dịch A nhận được một khóa trên một bản ghi nào đó, thì bản ghi đó sẽ không bị các giao dịch nào khác ngaòi A thay đổi trong quá trình A nhận khóa. Ý nghĩa của khóa là một giao dịch khóa lại không cho các gia dịch khác tham gia vào. Phương thức khóa được tiến hành như sau: Bai-9.doc *** Trang 6
  7. Cơ sở dữ liệu ThS. Lê Văn Lợi 1. Giả thiết rằng hệ thống có 2 loại khóa là khóa loại trừ - exclusive locks (hay còn gọi là khóa ghi – write locks), ký hiệu là khóa loại X và khóa chia sẻ - shared locks (hay còn gọi là khóa đọc – read locks) ký hiệu là laọi khóa S. Chúng ta giả thiết thêm rằng, chỉ có các bản ghi mới là các đối tượng có thể khóa được. Giả thiết này chỉ mang ý nghĩa minh họa. 2. Nếu giao dịch A đã giữ được một khóa loại X của bản ghi p, thì bất kỳ một giao dịch B khác nếu yêu cầu khóa sẽ bị từ chối. 3. Nếu giao dịch A giữ khóa S của bản ghi p thì có 2 trường hợp xảy ra: − Nếu giao dịch B yêu cầu khóa X của bản ghi p thì sẽ bị từ chối; − Nếu giao dịch B yêu cầu khóa S của bản ghi p thì sẽ được cấp (tức là B đồng thời cũng được phép giữ khóa S). Các qui tắc này được gói gọn như trong bảng tương thích sau: Giao dịch A X S - X N N Y S N Y Y - Y Y Y Giao dịch B Bảng này được giải thích như sau: giả thiết có một bản ghi p; giả thiết giao dịch A giữ khóa ký hiệu trên hàng trên cùng của bảng ( gạch ngang (-) = không khóa); giả thiết giao dịch B muốn nhận một khóa ký hiệu trong cột trái cùng của bảng. N là ký hiệu B sẽ không nhận được khóa; Y ký hiệu B sẽ nhận được khóa. Bây giờ chúng ta đưa vào giao thức truy cập dữ liệu, sử dụng các loại khóa X và S để đảm bảo các vấn đề tranh chấp không xảy ra: 1. Nếu một giao dịch nào đó muốn đọc dữ liệu trên một bản ghi thì trước hết cần nhận khóa S; 2. Nếu một giao dịch nào đó muốn ghi dữ liệu lên bản ghi, cần trước hết nhận khóa X. Mặc dù giao dịch đó có thể đã có khóa S, vẫn cần chuyển khóa S đó sang khóa X. Chú ý: Việc nhận khóa trong một số trường hợp có thể ngầm định: trước khi đọc dữ liệu một số hệ thống có thể ngầm định là thêm yêu cầu khóa S. Tương tự như vậy, trước khi ghi, có thể ngầm định yêu cầu khóa X. Ghi dữ liệu đồng nghĩa với việc sử dụng môt trong các lệnh INSERT, DELETE và UPDATE. 3. Nếu một giao dịch B yêu cầu nhận khóa và bị từ chối, thì B sẽ ở vào trạng đợi đến dịch nhả thái cho khi giao A khóa. Chú ý: Hệ thống phải đảm bảo B không đợi đến vô tận. Một trong những Bai-9.doc *** Trang 7
  8. Cơ sở dữ liệu ThS. Lê Văn Lợi kỹ thuật để đảm bảo việc đợi vô tận không xảy ra là ai đến trước được cấp trước. 4. Nhìn chung, các khóa cần được giữ cho đến lúc thực hiện lệnh COMMIT hoặc thực hiện lệnh ROLLBACK. 2.3.- Khảo sát lại ba vấn đề tranh chấp Sau khi đưa vào khái niệm khóa, chúng ta thử tìm cách giải quyết ba vấn đề tranh chấp đã nêu ở phần trên. 2.3.1 Vấn đề cập nhật mất hiệu lực (lost update problem) Giả sử giao dịch A và giao dịch B diễn biến như trong hình vẽ sau, theo thứ tự thời gian và cùng tác động lên bản ghi p. Giao dịch A Giao dịch B T - - - - - - Lấy giá trị p - t1 (nhận khóa S của p) Lấy giá trị p - t2 (nhận khóa S của p) Sửa đổi giá trị p - t3 (Yêu cầu khóa X của p) Đợi - Sửa đổi giá trị p Đợi t4 (Yêu cầu khóa x của p) Đợi Đợi Đợi Đợi ↓ Đợi Đợi Giao dịch A lấy giá trị p vào thời điểm t1. Giao dịch B cũng lấy giá trị đó vào thời điểm t2. Giao dịch A sửa đổi giá trị của p vào thời điểm t3. Để thực hiện việc này, giao dịch A yêu cầu khóa X. Tuy nhiên yêu cầu này không được chấp nhận vì B giữ khóa S. Giao dịch B sửa đổi giá trị của p vào thời điểm t4. Và B cũng yêu cầu khóa X trước khi sửa. Yêu cầu này cũng không được chấp nhận. Tuy đã giải được vấn đề các giao dịch không ghi đè lên nhau, nhưng dẫn đến một vấn đề mới: tắc nghẽn (deadlock) – A và B khóa lẫn nhau. 2.3.2 Vấn đề tính phụ thuộc giao dịch chưa xử lý (uncommitted dependency problem) Vấn đề này xả y ra khi một giao dịch trích xuất (hoặc cập nhật) một bản ghi mà bản ghi đó được cập nhật bởi một giao dịch khác mà giao dịch khác này chưa được xử lý (COMMIT hoặc ROLLBACK). Xem tình huống này trong hình vẽ sau: Bai-9.doc *** Trang 8
  9. Cơ sở dữ liệu ThS. Lê Văn Lợi Giao dịch A Giao dịch B T - - - Cập nhật p - t1 (nhận khóa X của p) Lấy giá trị p - (Yêu cầu khóa S của p) đợi - t2 đợi t3 COMMIT/ROLLBACK (nhả khóa X của p) (Nhận được khóa S của P) - t4 Lấy giá trị của p - ↓ - - Giao dịch A Giao dịch B T - - - Cập nhật p - t1 (nhận khóa X của p) Cập nhật p - (Yêu cầu khóa X của p) đợi - t2 đợi COMMIT/ROLLBACK t3 (nhả khóa X của p) (Nhận được khóa X của p) - t4 Cập nhật p ↓ - - Trong cả 2 trường hợp trong hình vẽ trên, đến thời điểm t2, giao dịch A phải đợi vì giao dịch B đã có khóa X. Khi B đến thời điểm hoặc COMMIT hoặc ROLLBACK, B nhả khóa và lúc đó A mới nhận được khóa. Bai-9.doc *** Trang 9
  10. Cơ sở dữ liệu ThS. Lê Văn Lợi 2.3.3 Vấn đề phép toán gộp không nh ất quán (inconsistent analysis problem) TK1 TK2 TK3 40 50 30 Giao dịch A Giao dịch B T - - - - - Lấy GT TK1 - t1 (nhận được khóa S của TK1) sum = 40 Cộng thêm GT TK2 - t2 (nhận được khóa S của TK2) sum = 90 Lấy GT TK3 t3 (nhận khóa S của TK3) Cập nhật TK3 t4 (nhận khóa X của TK3) 30 → 20 Lấy GT TK1 t5 (nhận khóa S của TK1) Cập nhật TK1 t6 (Yêu cầu khóa X của TK1) đợi đợi t7 Cộng thêm GT TK3 đợi t8 (Yêu cầu khóa S của TK3) đợi đợi ↓ đợi đợi Trong hình vẽ trên, giao dịch A làm phép toán cộng giá trị các tài khoản, còn giao dịch B chuyển giá trị 10 từ tài khoản 3 vào tài khoản 1. Đến thời điểm t6, yêu cầu lấy khóa X của TK1 không được chấp nhận vì A đang giữ khóa đó. Vì vậy B phải đợi. Đến thời điểm t8, yêu cầu lấy khóa X của TK3 cũng không được chấp nhận vì B đang giữ khóa đó. Và ở đây, một tình thế tương tự xảy ra: tắc nghẽn (deadlock) A và B khóa lẫn nhau. Bai-9.doc *** Trang 10
  11. Cơ sở dữ liệu ThS. Lê Văn Lợi 2.4.- Tắc nghẽn (deadlock) Đến lúc này, chúng ta nhận thấy là k ỹ thuật dùng khóa sẽ tránh được các vấn đề tranh chấp nhưng đồng thời nó cũng sinh ra vấn đề của chính nó: tắc nghẽn (deadlock): các giao d ịch khóa lẫn nhau. Xét các trường hợp trên, chúng ta hiểu tắc nghẽn là một tình huống mà ở đó các giao dịch đợi lẫn nhau. Không phải chỉ có 2 giao dịch đợi lẫn nhau mà trong một số trường hợp, có thể có 3, 4, ... giao dịch đợi lẫn nhau, chờ nhau nhả khóa. Đây là vấn đề khá kinh điển trong xử lý hệ thống – không chỉ HQT CSDL gặp phải mà còn có cả ở các lĩnh vực khác, chẳng hạn như hệ điều hành. Nếu tắc nghẽn xảy ra, thì thông thường chỉ có các phần mềm thuộc hệ thống mới có khả năng tháo gỡ. Cách gỡ khóa phổ biến nhất là người ta chọn một nạn nhân theo qui tắc ngẫu nhiên và cho nạn nhân đó ROLLBACK. Sau khi ROLLBACK, nạn nhân này sẽ nhả khóa (sau khi ROLLBACK, các giao dịch sẽ tự động nhả khóa). Cách xử lý hậu quả của nạn nhân cũng tùy chiến lược xử lý của từng hệ thống. Có hệ thống sẽ tự động cho xử lý lại giao dịch. Có hệ thống chỉ báo lỗi cho chương trình (tiến trình). Sau đó là tùy chương trình (tiến trình). Chương trình (tiến trình) phải tự có phương án xử lý. 2.5.- Khả năng tuần tự hóa Khi xét vấn đề tranh chấp trong xử lý các giao dịch, nảy ra một vấn đề khác là: khi xử lý đan xen như vậy, liệu các thuật toán đó có đúng hay không, với giả thiết khi không chạy đan xen, bản thân các thuật toán đó là đúng? Khả năng tuần tự hóa (serializability) là một khái niệm về các tiêu chuẩn đảm bảo xử lý các tranh chấp là đúng (thuật toán chạy đúng). Hiện nay, nhìn chung người ta chấp nhận một xử lý đan xen mà cho kết quả giống hệt như xử lý theo tuần tự tách rời, từng giao dịch một, thì xử lý đan xen đó cho kết quả đúng. Nói một cách khác: 1. Giả thiết rằng các giao dịch nếu viết tách rời cho kết quả đúng, nghĩa là chúng chuyển CSDL từ một trạng thái ổn định này sang một trạng thái ổn định khác. 2. Vì vậ y, nếu chạy tách rời từng giao dịch một theo tuần tự, chúng ta cũng sẽ được kết quả đúng. Giả thiết là các giao dịch hoàn toàn độc lập với nhau. Bai-9.doc *** Trang 11
  12. Cơ sở dữ liệu ThS. Lê Văn Lợi 3. Một xử lý xen kẽ các giao dịch được gọi là đúng nếu nó tương đương với một tổ hợp xử lý tuần tự nào đó. Quay trở lại ba vấn đề tranh chấp, các xử lý đan xen đó không chạy đúng khi không tuần tự hóa được, nghĩa là chúng ta không tách được xử lý A rồi đến B hoặc xử lý B rồi đến A. Để tháo gỡ deadlock, người ta chọn nạn nhân để ROLLBACK. Cách này về bản chất cũng là cách tuần tự hóa các giao dịch. Một vài định nghĩa: Lịch xử lý = tổ hợp các giao dịch; Lịch xử lý tuần tự = tổ hợp các giao dịch tách rời và tuần tự; Lịch xử lý đan xen nếu các giao dịch đan xen; Hai lịch được gọi là tương đương nếu nó cho cùng một kết quả, nghĩa là cùng một trạng thái ổn định của CSDL. Điểm đáng lưu ý là hai lịch xử lý của cùng một tập hợp các giao dịch có thể cho kết quả khác nhau. Ví dụ, giao dịch A là “Thêm 1 vào x” và giao dịch B là “Nhân đôi x”, x là một giá trị thuộc CSDL. Giả thiết rằng giá trị lúc đầu của x là 10. Nếu ta chọn lịch A rồi đến B thì cho kết quả là x=22 trong lúc đó nếu chọn B rồi đến A thì cho kết quả là x=21. Trong kết quả nghiên cứu về khả năng tuần tự hóa của các giao dịch, người ta đã chứng minh được định lý khóa 2 pha như sau: Nếu tất cả các giao dịch đều tuân thủ giao thức khóa 2 pha thì tất cả các lịch đan xen đều có thể tuần tự hóa được. Giao thức khóa 2 pha được định nghĩa như sau: 1. Trước khi tác động lên bất cứ đối tượng nào, giao dịch cần nhận được khóa của đối tượng định xử lý; 2. Sau khi nhả khóa, thì giao dịch đó không bao giờ được nhận lại khóa một lần nữa. Nếu một giao dịch nào đó tuân thủ giao thức này thì giao thức sẽ gồm 2 pha: pha nhận khóa và pha nhả khóa. Ý nghĩa của giao thức này là nguyên tắc rất đơn giản và đảm bảo được tính đúng đắn của một thuật toán. Điểm đáng lưu ý nữa là nếu không tuân thủ giao thức 2 pha, các giao dịch đan xen có khả năng sẽ tạo ra một cấu trúc mắc lỗi tranh chấp. Bai-9.doc *** Trang 12
  13. Cơ sở dữ liệu ThS. Lê Văn Lợi 3./ A n toàn dữ liệu An toàn dữ liệu thường gắn liền với bảo mật (an ninh) và đảm bảo tính toàn vẹn của dữ liệu. Bảo mật = cho phép và không cho phép đối tượng truy cập dữ liệu; Tính toàn vẹn = độ chính xác và tính hợp lệ của dữ liệu. 1. Bảo mật là hệ thống cấp phép các đối tượng các quyền họ được phép thực thi với CSDL. 2. Tính toàn vẹn là việc đảm bảo các đối tượng thực thi đúng các công việc của họ. Cả hai vấn đề trên có các điểm chung: chúng phải tuân thủ các qui tắc do hệ thống đặt ra, các qui tắc này thông thường do DBA chỉ định (sử dụng ngôn ngữ SQL). Bảo mật thường gắn với các qui định và giải pháp khác ngoài HQT CSDL: − Về mặt xã hội, có thể có các luật qui định các hình phạt đối với những kẻ cố tình vi phạm; − Về mặt doanh nghiệp, có thể có các chế tài đối với nhân viên vi phạm các qui tắc đã đề ra; − Hệ điều hành cũng có các phương án riêng để bảo mật ở mức hệ thống. 3.1.- Kiểm soát truy cập dữ liệu Trong các mô hình kiểm soát truy cập dữ liệu hiện nay, phần lớn đều chọn cách tiếp cận tùy biến giữa ba lớp đối tượng đó là: người dùng (user), đối tượng dữ liệu và quyền truy xuất, như trong hình vẽ sau. Người dùng Dữ liệu Quyền truy xuất Lưu ý rằng mục tiêu của bảo mật là: chỉ cho phép người dùng thực hiện những gì đã được cấp phép. Bai-9.doc *** Trang 13
  14. Cơ sở dữ liệu ThS. Lê Văn Lợi Người dùng: là một tài khoản người dùng. Trong MySQL, người dùng được hiểu là (tên miền, tên tài khoản). Điều đó có nghĩa là cùng một tên là hocsinh trên máy itcsoft.com có thể hoàn toàn khác với hocsinh trên máy vielina.com. Cách viết các tài khoản người dùng trong MySQL: ’hocsinh’@’itcsoft.com’ và ’hocsinh’@’vielina.com’. Quyền truy xuất: là các thao tác mà người dùng được phép thực hiện. Khi chúng ta sử dụng SQL thì các quyền chính là các động từ của câu lệnh SQL (như INSERT, UPDATE, DELETE). Đối tượng dữ liệu: là các phần tử trong CSDL, chủ yếu có 3 loại đối tượng chính: tên CSDL, tên bảng, tên thuộc tính. Các quyền này được hệ thống kiểm soát như thế nào? Hệ thống kiểm soát các quyền thông qua 2 bước: Bước 1: Khi mới kết nối từ Client đến Server, Server sẽ kiểm tra xem cặp (username, password) có được phép kết nối đến Server CSDL hay không. Nếu không hợp lệ, người dùng bị từ chối kết nối ngay và tiếp theo không có bất cứ lệnh nào được xử lý. Bước 2: Sau khi đã kết nối rồi, mỗi một lần người dùng sử dụng một câu lệnh nào đó thì hệ thống lại kiểm tra xem người dùng đó có đủ quyền để sử dụng câu lệnh đó hay không. Chẳng hạn, nếu người dùng liệt kê một bảng và ra lệnh xóa cấu trúc một bảng khác thì hệ thống sẽ kiểm tra xem người dùng đó có quyền SELECT và DROP không. Tiếp theo, hệ thống phải kiểm tra xem câu lệnh tác động lên đối tượng nào (CSDL, bảng, thuộc tính) và đối tượng đó, người dùng có quyền thao tác hay không. Các quyền truy xuất nào tác động lên bảng? Đó là các câu lệnh có thể tác động lên các bảng. Ví dụ, đối với MySQL, đó là: SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, GRANT, REFERENCES, INDEX , ALTER, CREATE View, SHOW view Các quyền truy xuất nào tác động lên các thuộc tính? Đó chính là các câu lệnh có thể tác động lên các cột. Ví dụ, đối với MySQL, đó là: SELECT, INSERT, UPDATE, REFERENCES Để có thể biết AI có QUYỀN gì tác động lên ĐỐI TƯỢNG nào, HQT CSDL cần phải có cơ chế quản lý theo một cách nào đó. Chú ý rằng, HQT CSDL lại dùng chính các bảng để quản lý quyền truy cập (qui tắc #4 của Codd). Bai-9.doc *** Trang 14
  15. Cơ sở dữ liệu ThS. Lê Văn Lợi MySQL sử dụng CSDL có tên là mysql để quản lý quyền truy cập. Trong CSDL này, người ta dùng: − bảng có tên là user để quản lý các tài khoản truy cập, − bảng có tên là db để quản lý tài khoản đó có các quyền gì tác động lên CSDL nào, − bảng có tên là host để quản lý máy nào (thực chất là doamain name, ho ặc địa chỉ IP) có các quyền gì lên CSDL nào, − bảng có tên là tables_priv để quản lý quyền truy cập trên từng bảng và − bảng có tên là columns_priv để quản lý quyền truy cập trên từng thuộc tính. Lấy ví dụ, chúng ta xem cấu trúc bảng user (MySQL phiên bản 5.0): Mặ c TT Tên thuộc tính Kiểu dữ liệu Null? Khóa định Host 1 char(60) NO PRI User 2 char(16) NO PRI Password 3 char(41) NO Select_priv 4 enum('N','Y') NO N Insert_priv 5 enum('N','Y') NO N Update_priv 6 enum('N','Y') NO N Delete_priv 7 enum('N','Y') NO N Create_priv 8 enum('N','Y') NO N Drop_priv 9 enum('N','Y') NO N Reload_priv 10 enum('N','Y') NO N Shutdown_priv 11 enum('N','Y') NO N Process_priv 12 enum('N','Y') NO N File_priv 13 enum('N','Y') NO N Grant_priv 14 enum('N','Y') NO N References_priv 15 enum('N','Y') NO N Index_priv 16 enum('N','Y') NO N Alter_priv 17 enum('N','Y') NO N Show_db_priv 18 enum('N','Y') NO N Super_priv 19 enum('N','Y') NO N Create_tmp_table_priv enum('N','Y') 20 NO N Lock_tables_priv 21 enum('N','Y') NO N Execute_priv 22 enum('N','Y') NO N Repl_slave_priv 23 enum('N','Y') NO N Repl_client_priv 24 enum('N','Y') NO N Create_view_priv 25 enum('N','Y') NO N Show_view_priv 26 enum('N','Y') NO N Create_routine_priv enum('N','Y') 27 NO N Alter_routine_priv 28 enum('N','Y') NO N Bai-9.doc *** Trang 15
  16. Cơ sở dữ liệu ThS. Lê Văn Lợi Mặ c TT Tên thuộc tính Kiểu dữ liệu Null? Khóa định Create_user_priv 29 enum('N','Y') NO N ssl_type 30 enum('','ANY','X509','SPECIFIED') NO ssl_cipher 31 blob NO x509_issuer 32 blob NO x509_subject 33 blob NO max_questions 34 int(11) unsigned NO 0 max_updates 35 int(11) unsigned NO 0 max_connections 36 int(11) unsigned NO 0 max_user_connections 37 int(11) unsigned NO 0 3.2.- M ã hóa dữ liệu Xem cấu trúc của bảng user, chúng ta nhận thấy có cột password, là cột ghi mật khẩu của người dùng. Bằng một lệnh SELECT bình thường, chúng ta có thể thu được các thông tin (host, user, password): SELECT Host, User, Password FROM user; Và kết quả, ví dụ: Host User Password localhost root *575CA2693405215B49EA5ADDE0917BEB6435E74A Trong kết quả trên, chúng ta thấy giá trị của cột password đã được mã hóa. Nh ư vậy, password = f(‘mật khẩu’), trong đó f là hàm mã hóa. Khi người dùng nhập tên đăng nhập và mật khẩu thì dữ liệu là dữ liệu chưa mã hóa. Khi HQT CSDL so sánh xem người dùng có hợp lệ hay không thì dữ liệu so sánh là cặp (User, Password) nói trên. Giá trị trong cột Password là giá trị mã hóa của mật khẩu. User không mã hóa, chỉ có mật khẩu mới mã hóa. Hàm f có tên gọi là hàm hash (băm) dữ liệu. Bản gốc của dữ liệu có độ dài tùy ý, nhưng sau khi băm và trộn dữ liệu, kết quả là một dãy dữ liệu có độ dài cố định. Trong ví dụ trên, trường Password có độ dài là 41 ký tự. Một trong các đặc tính hàm f cần có là y = f-1(x) phải rất khó tính được trong một khoảng thời gian cho phép hoặc bất khả thi (hàm không tính ngược được). Tính chất này làm cho hacker khó tấn công hệ thống hơn. Mặt khác độ phức tạp của f cũng không được quá lớn (tiết kiệm thời gian tính toán). Sau đây, chúng ta xét một số hàm mã hóa dữ liệu. Bai-9.doc *** Trang 16
  17. Cơ sở dữ liệu ThS. Lê Văn Lợi 3.2.1 MD5 MD5 là giải thuật băm thông điệp, gọi là hàm băm mật mã. MD5 là hàm băm cho kết quả là 128 bit (16 bytes). Dãy các ký tự này đều là các chữ số hệ 16 (hexadecimal). Hiện nay MD5 được sử dụng trong rất nhiều ứng dụng về bảo mật và trên Internet giải thuật này được dùng để kiểm tra file tải về có nguyên vẹn hay không (hay là đã bị hacker tấn công giữa chừng lúc đang tải). Hiện nay, MD5 đã bị phá khóa (nghĩa là có người đã tìm ra được một kết quả hàm ngược). Ngày 18/03/2006, Vlastimil Klima đã cho xuất bản giải thuật tìm lại chuỗi ký tự lúc chưa bị băm (xem http://eprint.iacr.org/2006/105 ). Thời gian xử lý của giải thuật này chỉ trong một phút trên một máy xách tay có cấu hình trung bình. Người thiết kế giải thuật MD5 là Ron Rivest. Giải thuật này ra đời vào năm 1991. Ông cũng là đồng tác giả của RSA (xem phần sau). HQT CSDL MySQL cũng có hàm MD5(str). Đầu vào của MD5 là một dãy ký tự có độ dài tùy ý và đầu ra của MD5 là dãy ký tự có độ dài 32 ký tự, mỗi một ký tự là chữ số trong hệ hexadecimal (nghĩa là các ký tự 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F). Ví dụ: MD5("The quick brown fox jumps over the lazy dog") = 9e107d9d372bb6826bd81d3542a419d6 Chỉ cần một thay đổi nhỏ trong chuỗi ký tự gốc, kết quả cho ra một mã hóa khác hẳn: MD5("The quick brown fox jumps over the lazy cog") = 1055d3e698d289f2af8663725127bd4b Mã hóa chuỗi ký tự rỗng: MD5("") = d41d8cd98f00b204e9800998ecf8427e 3.2.2 SHA SHA là viết tắt của Secure Hash Algorithm. Tương tự như MD5, SHA cũng là hàm băm và cho kết quả là một dãy ký tự có độ dài cố định (SHA-1 cho kết quả có độ dài 20 bytes). Bai-9.doc *** Trang 17
  18. Cơ sở dữ liệu ThS. Lê Văn Lợi HQT CSDL MySQL có hàm sha1(str). Ví dụ: SHA1("The quick brown fox jumps over the lazy dog") = 2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12 Chỉ cần một thay đổi nhỏ trong chuỗi ký tự gốc, kết quả cho ra một mã hóa khác hẳn: SHA1("The quick brown fox jumps over the lazy cog") = de9f2c7f d25e1b3a fad3e85a 0bd17d9b 100db4b3 Mã hóa chuỗi ký tự rỗng: SHA1("") = da39a3ee 5e6b4b0d 3255bfef 95601890 afd80709 3.2.3 Mã hóa sử dụng chìa khóa công khai (RSA) Giải thuật có tên là RSA vì đặt theo tên những người đã sáng chế ra phương pháp này là Ron Rivest, Adi Shamir và Len Adleman, vào năm 1977. Giải thuật RSA vừa có thể dùng cho phương pháp mã hóa sử dụng chìa khóa công khai vừa có thể dùng cho chữ ký điện tử. Tính bảo mật của phương pháp này dựa trên nguyên lý rất khó có thể phân tích thành thừa số nguyên tố các số nguyên lớn. Người ta lấy ví dụ rằng để xác định xem một số nguyên có 130 chữ số thập phân có phải là số nguyên tố hay không thì mất khoảng 7 phút, còn để phân tích số đó thành 2 thừa số nguyên tố mà mỗi thừa số có 63 chữ số thập phân thì mất khoảng 40 triệu tỷ năm. Giải thuật tạo khóa: 1 . Tạo ra 2 số n guyên tố lớn, p và q, có độ lớ n xấp xỉ bằng nhau sao cho tích n = pq có độ dài cần thi ết, ví dụ 1 024 bit. 2. Tính n = pq và (φ) phi = (p-1)(q-1). 3. Chọn mộ t số n guyên e, 1 < e < phi, sao cho th ừa số chung l ớn nh ất (e, phi) = 1. (Nghĩ a là chúng nguyên tố cùng nhau.) 4. Tính số mũ bí mật d, 1 < d < phi, sao cho ed ≡ 1 (mod phi). 5. Chìa khóa công khai là (n, e) và chìa khóa bí mật là (n, d). Các giá trị củ a p, q, và phi cũ ng cần đượ c giữ bí mật. • n được gọi là modulo . • e được gọi là số mũ công khai hay còn gọi là số mũ mã hóa. • d được gọi là số mũ bí mật hay còn gọi là số mũ gi ải mã. Mã hóa: Bai-9.doc *** Trang 18
  19. Cơ sở dữ liệu ThS. Lê Văn Lợi Bên gửi A thao tác nh ư sau:- 1. Lấy chìa khóa công khai của bên nhận (n, e). 2. Bi ểu di ễn dữ li ệu cần gửi đi bằng một số nguyên m. 3. Tính ra đoạn mật mã c = m^e mod n. 4. Gửi đoạn mật mã c cho B. Giải mã: Bên nhận thao tác như sau:- 1. S ử dụng khóa bí mật (n, d) để tính m = c^d mod n. 2. Lấy l ại văn bản gốc từ số nguyên m. 3.3.- Cấp quyền và hủy quyền Cấp quyền được thực hiện bằng câu lệnh SQL là GRANT và hủy quyền được thực hiện bằng câu lệnh REVOKE. GRANT privilege-commalist ON object TO user-commalist [WITH GRANT OPTION]; REVOKE privilege-commalist ON object FROM user-commalist option; Giải thích: privilege-commalist: là danh sách các quyền object: đối tượng CSDL (tên CSDL, tên bảng) user-commalist: danh sách các tài kho ản người dùng WITH GRANT OPTION: quyền được phép phân quyền option: các tùy ch ọn. Phần này tùy vào các HQT CSDL ch ỉ định. Đối với MySQL (phiên bản 5.0): GRANT priv_type [(column_list)] [, priv_type [(column_list)]] ... ON [object_type] {tbl_name | * | *.* | db_name.*} TO user [IDENTIFIED BY [PASSWORD] 'password'] [, user [IDENTIFIED BY [PASSWORD] 'password']] ... [REQUIRE NONE | [{SSL| X509}] [CIPHER 'cipher' [AND]] [ISSUER 'issuer' [AND]] [SUBJECT 'subject']] [WITH with_option [with_option] ...] object_type = TABLE | FUNCTION | PROCEDURE with_option = GRANT OPTION | MAX_QUERIES_PER_HOUR count | MAX_UPDATES_PER_HOUR count Bai-9.doc *** Trang 19
  20. Cơ sở dữ liệu ThS. Lê Văn Lợi | MAX_CONNECTIONS_PER_HOUR count | MAX_USER_CONNECTIONS count REVOKE priv_type [(column_list)] [, priv_type [(column_list)]] ... ON [object_type] {tbl_name | * | *.* | db_name.*} FROM user [, user] ... REVOKE ALL PRIVILEGES, GRANT OPTION FROM user [, user] ... MySQL sử dụng câu lệnh GRANT để cấp luôn tài khoản người dùng. MySQL bổ sung thêm một số tùy chọn phù hợp với môi trường xử lý phân tán. [Sinh viên ghi chép thêm các giải thích tại lớp.] 4./ Đ ảm bảo tính toàn vẹn Tính toàn vẹn = tính đúng đắn và chính xác của dữ liệu. Dữ liệu như thế nào thì được gọi là đúng và chính xác? Quan điểm này trong CSDL được hiểu là đảm bảo mối quan hệ giữa các đối tượng và đảm bảo các ràng buộc không bị phá vỡ. Các ràng buộc rất đa dạng nên chỉ có một số rất ít trong số đó có thể khai báo được và có sự can thiệp của HQT CSDL. Phần lớn sẽ do người quản trị và lập trình đảm bảo. Đối với HQT CSDL, thường có 2 cách hỗ trợ các qui tắc đảm bảo tính toàn vẹn của dữ liệu: theo phương thức khai báo và theo phương thức thủ tục (hay còn gọi là phương thức lập trình). Phương thức khai báo có nhiều ưu việt cho người lập trình vì chỉ cần báo là cái gì liên quan đến cái gì theo qui tắc nào ... Tuy nhiên phương thức này lại làm cho HQT CSDL nặng hơn vì một mặt phải có các phương thức kiểm soát tất cả các khia báo, mặt khác phải kiểm tra các qui tắc ở mọi thời điểm. Phương thức thủ tục sẽ làm cho trách nhiệm của người lập trình cao hơn – qui tắc đúng hay có được đảm bảo hay không là do người lập trình. Nhìn chung, để có thể đảm bảo được các qui tắc phức tạp – chỉ có phương thức này mới có thể thực thi được. Câu hỏi được đặt ra là làm thế nào để cơ chế các qui tắc luôn luôn được thực thi? Người ta theo cách như sau: 1. Mỗi một lần một giao dịch nào đó được xử lý, người ta cho kiểm tra các ràng buộc xem các ràng buộc đó thỏa mãn hay bị vi phạm; 2. Nếu các ràng buộc đều thỏa mãn thì việc xử lý vẫn tiếp tục bình thường; 3. Nếu các qui tắc bị vi phạm thì người ta phải chỉ định một hành động để thực hiện khi vi phạm xảy ra. Bai-9.doc *** Trang 20
ADSENSE

CÓ THỂ BẠN MUỐN DOWNLOAD

THÔNG TIN
TRỢ GIÚP
HỖ TRỢ KHÁCH HÀNG
Theo dõi chúng tôi

Chịu trách nhiệm nội dung:

Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA

LIÊN HỆ

Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM

Hotline: 093 303 0098

Email: support@tailieu.vn

Giấy phép Mạng Xã Hội số: 670/GP-BTTTT cấp ngày 30/11/2015 Copyright © 2022-2032 TaiLieu.VN. All rights reserved.

 

Đồng bộ tài khoản
2=>2