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

Cơ sở dữ liệu ThS. Lê Văn Lợi Bai-9.doc *** Trang 1 B B à à i i 9 9 – – B B ả ả o o v v ệ ệ d d ữ ữ l l i i ệ ệ u 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. Cơ sở dữ liệu ThS. Lê Văn Lợi Bai-9.doc *** Trang 2 Để 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 Cơ sở dữ liệu ThS. Lê Văn Lợi Bai-9.doc *** Trang 3 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, I solation 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ỡ. Cơ sở dữ liệu ThS. Lê Văn Lợi Bai-9.doc *** Trang 4 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 T Giao dịch B - - - - - - Lấy giá trị p t1 - - t2 Lấy giá trị p Sửa ñổi giá trị p t3 - - t4 Sửa ñổi giá trị p - ↓ 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. Cơ sở dữ liệu ThS. Lê Văn Lợi Bai-9.doc *** Trang 5 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 T Giao dịch B - - - t1 - Cập nhật p Lấy giá trị p - - - t2 - t3 ROLLBACK - ↓ Giao dịch A T Giao dịch B - - - t1 - Cập nhật p Cập nhật p - - - t2 - t3 ROLLBACK - ↓ 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. Cơ sở dữ liệu ThS. Lê Văn Lợi Bai-9.doc *** Trang 6 2.1.3 Vấn ñề phép toán gộp không nhất quán (inconsistent analysis problem) TK1 TK2 TK3 Giao dịch A T Giao dịch B - - - - - Lấy GT TK 1 sum = 40 t1 - Cộng thêm GT TK2 sum = 90 t2 - t3 Lấy GT TK 3 t4 Cập nhật TK 3 30 → 20 t5 Lấy GT TK 1 - t6 Cập nhật TK 1 40 → 50 - t7 COMMIT Cộng thêm GT TK 3 sum = 110 t8 (Đú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: 40 50 30 Cơ sở dữ liệu ThS. Lê Văn Lợi Bai-9.doc *** Trang 7 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: X S - X N N Y S N Y Y - Y Y Y 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 thái ñợi cho ñến khi giao dịch A nhả khóa. Chú ý: Hệ thống phải ñảm bảo B không ñợi ñến vô tận. Một trong những Giao dịch A Giao dịch B Cơ sở dữ liệu ThS. Lê Văn Lợi Bai-9.doc *** Trang 8 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 T Giao dịch B - - - - - - Lấy giá trị p (nhận khóa S của p) t1 - - t2 Lấy giá trị p (nhận khóa S của p) Sửa ñổi giá trị p (Yêu cầu khóa X của p) t3 - Đợi - Đợi t4 Sửa ñổi giá trị p (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: Cơ sở dữ liệu ThS. Lê Văn Lợi Bai-9.doc *** Trang 9 Giao dịch A T Giao dịch B - - - t1 - Cập nhật p (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) Lấy giá trị của p t4 - - - ↓ - Giao dịch A T Giao dịch B - - - t1 - Cập nhật p (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 t3 COMMIT/ROLLBACK (nhả khóa X của p) (Nhận ñược khóa X của p) Cập nhật p t4 - - ↓ - 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. Cơ sở dữ liệu ThS. Lê Văn Lợi Bai-9.doc *** Trang 10 2.3.3 Vấn ñề phép toán gộp không nhất quán (inconsistent analysis problem) TK1 TK2 TK3 Giao dịch A T Giao dịch B - - - - - Lấy GT TK1 (nhận ñược khóa S của TK1) sum = 40 t1 - Cộng thêm GT TK2 (nhận ñược khóa S của TK2) sum = 90 t2 - t3 Lấy GT TK3 (nhận khóa S của TK3) t4 Cập nhật TK3 (nhận khóa X của TK3) 30 → 20 t5 Lấy GT TK1 (nhận khóa S của TK1) t6 Cập nhật TK1 (Yêu cầu khóa X của TK1) ñợi t7 ñợi Cộng thêm GT TK3 (Yêu cầu khóa S của TK3) t8 ñợi ñợ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. 40 50 30 [...]... Bai -9 . doc *** Trang 23 Cơ s d li u ThS Lê Văn L i 5./ Bài t p Bài t p 9. 1 – Khi m t giao d ch liên quan ñ n nhi u CSDL (database), các HQT CSDL nhìn chung không cho phép s d ng l nh COMMIT cho t ng CSDL m t (nghĩa là khi c p nh t CSDL a thì có COMMIT, CSDL b l i có m t l nh COMMIT khác) T i sao? Bài t p 9. 2 – Các giao d ch không ñư c l ng nhau T i sao? Bài t p 9. 3 – Nêu khái ni m kh năng tu n t hóa Bài. .. MD5("The quick brown fox jumps over the lazy cog") = 1055d3e 698 d289f2af8663725127bd4b Mã hóa chu i ký t r ng: MD5("") = d41d8cd98f00b204e980 099 8ecf8427e 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 Cơ s d li u ThS Lê Văn L i HQT CSDL MySQL có hàm sha1(str)... brown fox jumps over the lazy dog") = 2fd4e1c6 7a2d28fc ed849ee1 bb76e7 39 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 95 601 890 afd807 09 3.2.3 Mã hóa s d ng chìa khóa công khai ( RSA) Gi i thu t có... PRI N N N N N N N N N N N N N N N N N N N N N N N N N Bai -9 . doc *** Trang 15 Cơ s d li u ThS Lê Văn L i TT Tên thu c tính 29 30 31 32 33 34 35 36 37 Ki u d li u Create_user_priv ssl_type ssl_cipher x5 09_ issuer x5 09_ subject max_questions max_updates max_connections max_user_connections 3.2 .- Mã hóa d Null? Khóa enum('N','Y') NO enum('','ANY','X5 09' ,'SPECIFIED') NO blob NO blob NO blob NO int(11) unsigned... 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... i vào năm 199 1 Ô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... ñ ra không ñư c th a mãn khi c p nh t, HQT CSDL s cho b y ñ kích ho t m t ph n chương trình khác (ch ng h n như g i m t th t c lưu - stored procedures) 4.4 .- Qui t c trên các CSDL (database) Là các qui t c liên quan ñ n nhi u quan h trong cùng CSDL Bai -9 . doc *** Trang 22 Cơ s d li u ThS Lê Văn L i Khác v i các qui t c trên, các ràng bu c trên CSDL ph i lùi th i ñi m ki m tra ñ n th i ñi m ngay trư c... user [IDENTIFIED BY [PASSWORD] 'password']] [REQUIRE NONE | [{SSL| X5 09} ] [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 Cơ s d li u ThS Lê Văn L i | MAX_CONNECTIONS_PER_HOUR count | MAX_USER_CONNECTIONS... 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 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ó... 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 Cơ s d li . B - - - t1 - Cập nhật p Lấy giá trị p - - - t2 - t3 ROLLBACK - ↓ Giao dịch A T Giao dịch B - - - t1 - Cập nhật p Cập nhật p - - - t2 - t3 ROLLBACK - ↓. Cơ sở dữ liệu ThS. Lê Văn Lợi Bai -9 . doc *** Trang 9 Giao dịch A T Giao dịch B - - - t1 - Cập nhật p (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 -. bản ghi p. Giao dịch A T Giao dịch B - - - - - - Lấy giá trị p t1 - - t2 Lấy giá trị p Sửa ñổi giá trị p t3 - - t4 Sửa ñổi giá trị p - ↓ Giao dịch A lấy giá trị p vào