Please enable JavaScript.
Coggle requires JavaScript to display documents.
Hệ quản trị - cơ sở dữ liệu - Coggle Diagram
Hệ quản trị - cơ sở dữ liệu
Chương 1: Tại sa phải cần HQT CSDL?
Lí do vì:
dữ liệu trong CSDL có những đặc trưng:
ít trùng lặp
chia sẽ cho nhiều người (truy xuất đồng thời)
an ninh, bảo mật
cần khôi phục khi có sự cố
mang tính độc lập (về cả luận lý (logical) & vật lý)
Kiến trúc của HQT - CSDL gồm:
Giao giao diện
An ninh & bảo mật
Xử lý truy xuất đồng thời
Khôi phục sau sự cố
Tối ưu hóa truy vấn
Tổ chức & quản lý dữ liệu
chi tiết thì đọc slide
Xử lý truy xuất đồng thời
Có các khái niệm & vấn đề liên quan như:
Giao tác
Điều khiển đồng thời (cơ chế lập lịch, cơ chế khóa (lock), giải quyết deadlock )
Phân loại HQT CSDL:
Theo mô hình dữ liệu:
mạng
phân cấp
quan hệ (sử dụng phổ biến nhất)
hướng đối tượng
XML
Theo kiến trúc:
client /server
Tập trung/ phân tán
Hệ thống chịu lỗi tốt
Giao tác & Lịch giao tác
Giao tác (Transaction)
là tập hợp những câu lệnh mà [
có thứ tự
], [
có liên quan đến truy xuất CSDL
] và [
phải hoàn thành chọn vẹn một đơn vị công việc
]
Có tính ACID
A (Atomicity): Tính nguyên tố (chia nhỏ ko dc nữa)
(đại khái: trong giao tác có ý nghĩa là các câu lệnh phải hoành thành tuyệt đối)
Câu hỏi: Vì sao tính nguyên tố lại quan trọng?
(tưởng tượng: giao tác rút tiền, giao tác phúc tra điểm để xét học bổng) => nếu ko đúng đắn/ trọn vẹn tuyệt đối (được ví như nguyên tố) => thì hậu quả sẽ là gì? => dữ liệu sai, mâu thuẫn. Rất nguy hiểm!
Câu hỏi 2: có những giao tác có 7-8 câu lệnh nhưng bỏ sót cũng chẳng ảnh hưởng gì (vd: như xuất thông báo...) => vậy tại sao tính nguyên tố của giao tác lại đòi hỏi tuyệt đối như vậy? => câu trả lời: là máy tính (cụ thể là HQT CSDL) ko có tính phán xét biết được câu lệnh nào cần hay ko mà bỏ => vì vậy nó phải gôm hết tất cả (=> tính nguyên tố) đảm bảo thực hiện giao tác một cách trọn vẹn
Vấn đề sẽ được giải quyết ở chương 3 & 4 (trọng điểm là chương 4)
C (Consistancy): Tính nhất quán
(đại khái: ko vi phạm ràng buộc toàn vẹn)
Đặt vấn đề:
vd: điểm sinh viên <=10 (các dữ liệu trong CSDL hiện đang ở trạng thái nhất quán nghĩa là ko vi
phạm RBTV >10). Khi thao tác (thêm, xóa, sửa) => CSDL sẽ chuyển sang trạng thái khác => trạng thái này cũng phải đảm bảo được sự NHẤT QUÁN!
TÓM: một giao tác phải đưa CSDL đi từ trạng thái nhất quán này sang trạng thái nhất quán khác (Đây là câu nói của mấy ông viết sách => làm cho mình khó hiểu :smiley: khi học)
Đã dc giải quyết trong môn CSDL (lúc viết triger hoặc RBTV)
Thử viết lại triger
I (Isolation): Tính cô lập
(giúp tránh sự tranh chấp & xung đột dữ liệu )
Mỗi một giao tác dù cho đang vận hành trong 1 bối cảnh (trong TH) truy xuất đồng thời. Nghĩa là ông này bà kia 1000 người đang truy xuất. Thì vẫn phải được cô lập tách khỏi sự ảnh hưởng của những giao tác đang chạy song song để có thể hoành thành chính xác công việc của mình!
- Nếu ko có tính này các giao tác có thể xung đột => gây ra rất nhiều sự sai sót nguy hiểm
(ở chương 3: Sẽ đc thấy những kịch bản đó)
giải quyết trong chương 3
D: Duration - Tính bền vững
Dữ liệu được ghi bởi các giao tác đã hoàn thành (trên buffer) cần phải đc lưu trữ bền vững ra đĩa bất chấp có sự cố gì xảy ra
Vậy khi từ buffer chưa kịp đưa giữ liệu xuống đĩa thì khắc phục như thế nào nếu có sự cố?? Giải pháp ở chương 4
(nghe lại trước khi học chương 4 – recor 38p30s)
Các hành động/ thao tác của giao tác
Input
Output
Read
Write
Các trạng thái của giao tác
Begin => Committed => Rollback/ abort ...blabla
Lịch giao tác (Schedule)
(tập hợp các giao tác)
Phân loại:
Lịch tuần tự
Lịch đồng thời
so sánh 2 lịch này?
Tuần tự:
Ưu điểm:
ko xảy ra tranh chấp giữa các giao tác chạy đồng => kq đúng
Khuyết điểm:
phi thực tế quá chậm => ko ai dùng (vd: các quầy tính tiền trong siêu thị)
Câu hỏi: Vì sao nó phi thực tế nhưng vẫn cần tới? => dùng ưu điểm của nó để check cho lịch đồng thời
Đồng thời:
Khuyết điểm:
Xảy ra rất nhiều tranh chấp dữ liệu giữa các giao tác => nguy cơ sai rất cao
Ưu điểm:
cả thế giới đang dùng
Khuyết điểm của lịch đồng thời => Chương 3 solve!
Lịch khả tuần tự (Serial)
các giao tác => tạo ra 1 lịch đồng thời S được gọi là khả tuần tự nếu như nó cho ra kết quả sau cùng trên dữ liệu giống với kết quả sau cùng của 1 trong những lịch tuần tự được lập nên từ chính những giao tác mà tạo nên lịch S này
vd: cho 3 giao tác T1, T2, T3:
kq của lịch đồng thời: T2, T1, T3
Có bao nhiêu kết quả lịch S được tạo nên từ 3 giao tác đó => 3! = 6 giao tác. Vậy giống kq của lịch đồng thời giống với 1 trong các kq này của lịch này thì => nó dc gọi là lịch khả tuần tự => và ĐÚNG
- NOTE: nói kết quả có thể của lịch tuần tự S là 6 nhưng thực ra chỉ có 2 đá án thôi!!!
Xét theo các khối lệnh của mỗi giao tác trong lịch
Lịch khả tuần tự xung đột
(Serializable)
(Khái niệm quan trọng)
(hầu hết các thuật toán ở chương 3 những thuật toán quan trọng đang được giới công nghiệp áp dụng nhiều nhất thì nó tạo ra 1 lịch khả tuần tự đặc biệt => gọi là khả tuần tự xung đột) =>(theo mình nghỉ) đơn giản là dùng thuật toán để kiểm tra xem lịch khác tuần tự có bị xung đột ko và để ép lịch đồng thời chạy đúng - bằng cách tìm ra lịch tuần tự từ các giao tác của nó
Câu hỏi: Vậy thì lịch khả tuần tự xung đột có ý nghĩa gì?
(Tự rút ra từ bài học) Khi 1 lịch động thời được chứng nhận là khả tuần tự xung đột thì ta có thể yên tâm là nó chạy đúng (cho bất cứ TH nào) khi sử dụng cơ chế chạy đồng thời cho lịch này. Và thực tế lịch này được dùng rất phổ biến
(2) - KN: Tương đương xung đột:
Nếu lịch S có thể đc chuyển thành lịch S' (
LÀ LỊCH TUẦN TỰ
) bởi 1 chuỗi những thao tác hoán vị các cặp lệnh thuộc về 2 giao tác khác nhau, liên tiếp nhau về mặt thời gian và
ko phải là cặp lệnh xung đột
(Tương đương xung đột ở đây hiểu và dịch ra cụ thể là 2 lịch S và S' là 2 lịch tượng đương với nhau về khía cạnh các cặp lệnh xung đột) => lý do là ta hoán vị chỉ hoán vị các cặp lệnh
không xung đột
mà thôi - còn các cặp lệnh xung đột ta đâu có đụng tới => nên các cặp lệnh xung đột của S và S' đâu có thay đổi
- Học kĩ cái điều kiện này nha - đi thi ứng dụng đó
(1) - KN: Cặp lệnh xung đột thỏa tất cả các yêu cầu (phải thỏa 3 đk) sau:
+ Mỗi lệnh thuộc 1 giao tác khác nhau
+ Hai lệnh cùng truy xuất một đơn vị dữ liệu (source / trong sql - là table)
+ 1 trong 2 lệnh phải là GHI
(3) KN: lịch khả tuần tự xung đột: Lịch S được gọi là khả tuần tự xung đột
nếu như nó tương đương xung đột với 1 lịch tuần tự
Nếu bài toán có quá nhiều giao tác => Áp dụng các khái niệm này sẽ ko giải quyết hay trả lời cho câu hỏi yes cho 1 bài toán được! => nên ta phải cần 1 thuật toán
(Xem video B3 - 3: 3':40s/ 7'11s)
Dùng thuật toán kiểm tra lịch có Khả tuần tự xung đột (KTTXĐ) hay ko?
=> thuật toán Precedence Graph P(S) (gọi là đồ thị trình tự/ đồ thị ưu tiên)
Gồm:
đỉnh là: các giao tác của lịch S
cạnh: (Xem lại lý thuyết)
nếu P(S)
KHÔNG CÓ
chu trình thì lịch S là
lịch khả tuần tự XUNG ĐỘT
nếu P(S)
CÓ
chu trình thì lịch S là
lịch KHÔNG khả tuần tự XUNG ĐỘT
Chiến thuật làm bài (độc quyền của thầy)
cách làm chia để trị theo đơn vị dữ liệu (source / trong sql - là table)
Chọn nhóm lệnh (
đi theo lệnh W - bởi vì chỉ có W mới tạo nên cặp lệnh xung đột (đọc lại "2 cặp lệnh xung đột: "2 giao tác khác nhau phải chứa ít nhất 1 lệnh ghi")
) trên đvdl đó.
=> xét lần lượt nhóm lệnh (vd: nhóm lệnh W) đó trên đơn vị dữ liệu (cái nào tạo xung đột với nó?)
Vẽ mũi tên: xác định hướng mũi tên. Cái nào xảy ra trước vẽ trước
3 more items...
câu hỏi: tại sao người ta biết - các cái lệnh mà tạo thành graph tạo ra chu trình thì ko phải là lịch khả tuần tự xung đột?
Có thể chu trình là 1 công việc nên các câu lệnh có liên quan đến nhau vì thế mà nó ko tạo ra lịch khả tuần tự xung đột?
1 more item...
Đơn vị dữ liệu
: có thể là 1 giá trị (có thể bị thay đổi) và tồn tại trong csdl => cái này mình tự rút ra
(giá trị ở đây có thể là bất cữ dữ liệu gì! - thầy nói: 15'40/19'20 video b4 - p1)
Chú ý từ
ĐÚNG
là từ quan trọng
MẤU CHỐT CỦA BÀI NÀY LÀ do thực tế người ta chỉ muốn dùng lịch đồng thời mà ko thích dùng lịch tuần tự. Mà lịch đồng thời thì nó
RẤT DỄ SAI
ko đúng => vậy để dùng lịch đồng thời hiệu quả thì ta phải kèm theo 1 lịch tuần tự. Như vậy thì dùng lịch đồng thời sẽ ko sợ sai sót nữa => lịch tuần tự nó sẽ hỗ trợ lịch đồng thời kiếm tra tính
ĐÚNG
=> mà để dùng lịch đồng thời thì ta phải sử dụng LỊCH KHẢ TUẦN TỰ => (mà thị trường có rất nhiều lịch khả tuần tự khác nhau). Nhưng phổ biến và hiệu quả nhất vẫn là
LỊCH KHẢ TUẦN TỰ XUNG ĐỘT!!!!
Điều khiển truy xuất đồng thời
(Quan trọng)
(1) Trước khi tìm hiểu làm sao để ép cho lịch đồng thời đó chạy đúng (nói cách khác là làm cho lịch đồng thời nó khả tuần tự) thì ta phải biết qua trường hợp (Kịch bản) tranh chấp của lịch đồng thời đó
Vấn đề về tranh chấp giữa các giao tác trong truy xuất đồng thời:
trong thực tế có hàng vạn cuộc tranh chấp giữa các giao tác => nhưng đúc kết lại cho dù bao nhiêu giao tác đang tranh chấp với nhau đi nữa thì mỗi cuộc tranh chấp xảy ra tại mỗi thời điểm thì chỉ là giữa 2 giac tác mà thôi (quy nạp?)
Vậy các vấn đề/ trường hợp (
or kịch bản
) tranh chấp/ xung đột xảy ra trên các giao tác đó là gì?
(chỉ có 4 kiểu tranh chấp duy nhất)
Mất dl cập nhật (Lost update)
Kỹ thuật: tìm dấu hiệu nhận biết: xem B4-1=> 8p14s hoặc 11p45s (biết cái này để làm đồ án) <= xem kĩ lại video phần này
xem từ phút 15'/ 19'20- video B4 - p1:
vd: xem xong hãy tưởng tượng:
ta đang thực hiện giao tác rút tiền trong tài khoản (tổng là 100.000đ) và rút ra là 50.000đ, thì bỗng nhiên có người chuyển vào tk của ta thêm 20.000đ trong khi đang rút !!! - Đoán xem chuyện gì sẽ xảy ra nếu như xuất hiện vấn đề này trong truy xuất đồng thời?
Ta sẽ rút được 50.000đ nhưng tiền trong tài khoảng ta chỉ còn lại 50.000đ thay vì 70.000đ! => Khi read cùng 1 đơn vị dữ liệu (cụ thể là: 100.000) và ghi xuống trong 1 khoảng thời gian khác nhau mất dữ liệu cập nhật sẽ xảy ra !!!
Đọc ghi dữ liệu rác (Dirty read)
Không thể đọc lại dữ liệu (unrepeatable read)
Coi lại video để hiểu ý thầy nói và đọc vd dưới này:
Vd: hãy tưởng tượng - ta thấy trên mạng có bán 1 cái đèn ngủ 250.000đ và có ý định mua nó nên ta vào đt check xem TK mình có đủ tiền mua không nếu ko thì phải nạp thêm - vào check thì ta chỉ có 200.000đ và còn thiếu đến 50.000đ nữa mới đủ. Lúc này ta nghĩ mình chỉ cần nạp thêm 50.000đ là ok => nhưng khi ta nạp thêm 50.000đ cũng trong lúc này ngân hàng bắt đầu trừ phí duy trì thẻ là 15.000đ (nhưng ta ko biết điều đó và trên tài khoản con số đang read hiện giờ ta thấy trên màn hình đt vẫn là 200.000đ) => sau khi ta nạp thêm 50.000đ thì lúc này tk ta có 250.000đ và tưởng rằng nó là giá trị thực tại - nên vào shoppee click chuột mua liền món hàng - bất chợt bị cửa hàng thông báo: "tài khoản của quý khách ko đủ để thực hiện thanh toán" => thế là trong đầu lúc này hiện lên 1 câu hỏi lớn (ngạc nhiện: ỦA - nảy mới nạp thêm 50k mà ta??? sao giờ bị trừ 15k rồi - kì zậy) => thế là đỗ lỗi cho ngân hàng (thực chất đó là lỗi của HQT - csdl cùn mà ngân hàng đó sử dụng ko giải quyết dc vấn đề unrepeatable read)
(lưu ý: đây chỉ là ví dụ vui - chứ thực tế thì ko hề có nha - vì hầu hết các HQT-CSDL bây giờ là xịn xò hế rồi)
nạp thêm 50k vào đó là ta đang "xử lý trên dữ liệu lỗi thời mà thầy đã nói "
Lỗi bóng ma (phantom)
(lỗi này giống unrepeatable - nhưng nó thảy đổi trên 1 tập hợp đơn vị dữ liệu)
vd: ngày mùng 8/3 thầy nói
Câu hỏi (mình hỏi): liệu cả 4 trường hợp này có thể xảy ra chung cùng với nhau hay ko?
(2) Kỹ thuật khóa
(
Nội dung nhánh này rất quan trọng - câu 2
)
Khóa đọc/ ghi
Quy tắc 1: (gọi là giao tác/ lịch đúng đắn)
Khi giao tác T
muốn đọc
dữ liệu A, thì nó phải
phát khóa đọc
hoặc
khóa ghi
lên dữ liệu A, khi giao tác T
muốn ghi
vào dữ liệu A thì nó phải
phát khóa ghi
lên dữ liệu A. Sau khi giao tác T đã sử dụng xong dữ liệu A thì nó phải
nhả khóa
khỏi dữ liệu A
Note: ko được phát cả khóa ghi & đọc trong cùng 1 câu lệnh - chỉ được phát 1 khóa duy nhất.
Tại sao muốn đọc thì phải phát khóa đọc HOẶC khóa ghi?
=>
hành động ghi (write) việc xung đột sẽ xảy ra cao hơn
=> B4 - 3 (18p) (
nên xem lại
)
Chú ý: phút 19 s 20
(KHÓA ĐỌC RL YẾU HƠN KHÓA GHI WL)
vd: như đã nói trên mỗi giao chỉ sử dụng 1 khóa duy nhất.
Giả sử 1: nếu giao tác A chỉ đọc dữ liệu thì ta chỉ dùng khóa RL. Nhưng vì RL yếu. Nếu bất chợt có 1 giao tác khác chen vào và GHI xuống thì xẽ xảy ra xung đột =>
gây ra 4 vấn đề tranh chấp đã nói
=> gây ra việc sai dữ liệu...
Giả sử 2: nếu giao tác A đó cần thực hiện cả hành động ghi và đọc thì ta dùng khóa WL (vì WL nó mạnh hơn và nó có khả năng bảo vệ tốt hơn)
Ví dụ thực tế (quan trọng)
tôi cần xem số tiền trong tk ngân hàng có đúng là 100.000 đ không (vì hôm qua tui xem trên đt là nó báo quý khách còn 100.000 trong thẻ)? Để kiểm chứng tôi đi vào trạm ATM kiểm tra nhưng khi vào cây ATM bất nút show tiền (đọc dữ liệu) lên thì ngay trong lúc đọc dữ liệu THÌ ngân hàng trừ tiền phí giai hạn thẻ của tôi và lập tức tôi mất 5.000 và nó ghi xuống csdl của nó. Và bạn đoán xem Tài khoản ngân hàng hiển thị lên màn hình máy tính của tôi lúc này sẽ là 100.000đ hay 95.000đ?
=> câu trả lời dĩ nhiên là 95.000đ (ko ngân hàng nào đc sai sót chuyện này!)
nếu tôi sử dụng khóa đọc (RL) trong trường hợp này thì nó chỉ có thể giúp/ bảo vệ tôi tránh khỏi những cái việc là "trong lúc nó đang đọc dữ liệu - để hiển thị lên cho tôi thấy thì không thao tác nào của các giao tác khác có thể xen vào thực hiện tính toán/ xử lý..." nhưng nếu gặp lệnh write của 1 giao tác khác (vd: tiền phí giai hạn thẻ) như đã nói ở trên thì nó sẽ ra sao? nhường hành động lại cho giao tác đó hoặc sẽ dẫn đến trường hợp xung đột vs giao tác đó? (coi lại 4 TH tranh chấp). Vậy rõ ràng nếu muốn hiện 100.000đ mà ko phải là 95.000đ thì mình cần phải dùng WL (khóa ghi) để giao tác của ngân hàng ko thể can thiệp vào.
Câu hỏi: Nhưng nếu ta đang gắn WL vào cho giao tác (cụ thể là trên 1 đơn vị dữ liệu A nào đó rồi) thì lúc này một giao tác khác "chạy đến xin" gắn RL hay WL của nó vào vậy có được ko?
(Xem B4-4 => phút thứ 10 quy tắc 2)
Chú ý: giao tác nào thỏa qui tắc 1 thì gọi là
giao tắc đúng đắn
=> Vậy kết luận lịch S thảo qui tắc 1 (nghĩa là tất cả các giao tác trong lịch S đó phải giao tắc đúng đắn)
Ta biết khi khóa thì những tác động của câu lệnh/ thao tác vào đơn vị dữ liệu từ các câu lệnh khác trong cùng 1 giao tác HAY từ các giao tác khác là không thể được cho đến khi được nhả khóa
(nhưng nhả khóa cũng cần phải xem xét liệu những câu lệnh or giao tác khác có sử dụng hoặc liên quan đến nó hay ko?. Vậy phải biết để nhả cho phù hợp)
xem phần đầu video B4 - 4)! (nhưng điều này chỉ đúng nhất với khóa ghi còn khóa đọc liệu có mạnh đến vậy?)
Quy tắc 2: (quy tắc về
lịch hợp lệ
)
1 Lịch S được gọi là 1 lịch hợp lệ nếu
tất cả các giao tác
trong lịch S đều
tuân thủ ma trận tương thích
8p10s
Nắm khái niệm khóa W, R còn được gọi là
Khóa chia sẽ (SL: Share look)
Khóa độc quyền (XL) (Exclusive look)
Xét bảng ma trận tương thích:
Nếu 1 giao tác T1 đang sử dụng 1 khóa mà không cho phép T2 sử dụng khóa đọc/ ghi khác lên cùng đơn vị dữ liệu đó thì bắt buộc T2 phải CHỜ!
Qui tắc 3: (Nghi thức khóa 2 giai đoạn (cụ thể là LOOK & UNLOOK))
1 giao tác T được gọi là nghi thức khóa 2 giai đoạn nếu. Một khi T nhả lần đầu tiên dù là nhả khóa trên bất kì đơn vị dữ liệu nào thì T sẽ ko dc phát khóa thêm một lần nào nữa dù là phát khóa lên 1 dữ liệu khác (ko phải dữ liệu nó đã nhả khóa ban nảy)
Lịch S được gọi là thỏa nghi thức khóa 2 giai đoạn nếu như tất cả các giao tác T trong lịch S đều thỏa nghi thức khóa 2 giai đoạn
Vẽ đồ thị chờ
Lưu ý khi vẽ mũi tên cho câu 2:
=> - nhớ chữ:"Giao tác T này chờ giao tác T kia" vẽ mũi tên hướng ra từ T đang chờ
Vd: T2 chờ T1 vẽ mũi tên hướng từ T2 ra/ qua T1
(mũi tên vẽ ngược lại so với câu 1)
Tại sao vẽ mũi ten ngược mà ko vẽ mũi tên thuận như câu 1 ^^ (chắc lệnh W, R khác lệnh WL, RL)
Lưu ý đồ thị này chỉ kết luận ở mức tổng quát: Có nghĩa là khi vẽ đồ thị:
Nếu nó có chu trình thì ta nói: "Lịch S KHÔNG khả tuần tự" (ko có ghi chữ "xung đột" vào nhe)
ĐỊNH LÝ:
Nếu 1 lịch S thỏa đầy đủ cả 3 quy tắc của kỹ thuật khóa đọc/ ghi => thì
lịch S khả tuần tự xung đột
=> là cái lịch mà mọi HQT- CSDL trên thế giới này đang sử dụng =))
Đọc 4 kiểu/ vấn đề tranh chấp trước khi đọc cái này
Ý tưởng:
Khi 1 giao tác T muốn sử dụng dữ liệu A thì nó sẽ khóa dữ liệu a đó lại - để ngăn chặn sự chi phối khác làm thay đổi A hoặc sử dụng A
tự rút: Cho chương trình sử dụng cơ chế chạy đồng thời NHƯNG phải khóa lại những thứ quan trọng ??? có phải dậy khum
có 1 vấn đề quan trọng về vấn đề giao tác là: các giao tác thực tế phải chạy tuần tự (cho dù nó đang sử dụng cơ chế đồng thời)
Kỹ thuật nhãn thời gian
Ý tưởng:
-TH1: Nếu T1 truy xuất A, T2 truy xuất B => cho T nào truy xuất trước cũng được (nghĩa là máy cho truy xuất ngẫu nhiêu bất kì) - này giống bài multi-thread java
-TH2: Nếu T1 truy xuất C, T2 truy xuất C => thì bắt buộc 1 cái phải chạy trước! (hay nói cách khác cái nào begin trước truy xuất trước, cái nào sau truy xuất sau)
Các khái niệm
KN: Nhãn thời gian của giao tác
Ký hiệu: (TimeStamp => TS(S))
Là một con số duy nhất dành cho T (ko trùng với giao tác khác) với quy tắc: T' begin sau T khi và chỉ khi TS(T') > TS(T)
Mục đích của nó là để biết T nào trước T nào sau
KN: Nhãn thời gian của 1 đơn vị dữ liệu
Mỗi 1 đơn vị dữ liệu A sẽ được gắn với 2 nhãn thời gian. Gọi là
nhãn đọc
của A &
nhãn ghi
của A
Nhãn đọc RT(A) (Read timestamp): là ghi nhận nhãn thời gian lớn nhất của 1 giao tác nào đó trong lịch
(Phần này thầy đọc sai => đã sửa)
Tại sao phải phân ra nhãn đọc & nhãn ghi cho đơn vị dữ liệu?
mục đích là để biết được T nào truy xuất trước T nào truy xuất sau (nôm na là ta biết được thứ tự truy xuất của các giao tác vào A)! => giống mục đích của nhãn thời gian giao tác quá :))
nhưng điểm quan trọng hơn là biết được hay kiểm soát được thứ tự của các giao tác vào A (điều này có nghĩa là
- hãy đọc lại ý tưởng và tưởng tượng nếu nó ko kiểm soát thì các giao tác sẽ bị truy xuất cùng 1 đơn vị dữ liệu sẽ bị chạy sai nữa thì sao? đúng ko) => như vậy cần thuật tóan để giải quyết vấn đề này là phải kéo nó về 1 trật tự nào đó để nó ko xảy ra tình trạng trên
Thuật toán
Qui tắc đọc
T xin đọc A
Nếu TS(A) >= WT(A)
Cho phép T đọc A ..
đọc slide đi
Qui tắc ghi
Nhãn ghi WT(A): là nhãn ghi nhận giao tác sau cùng trong lịch
mục đích của ý tưởng này là để đảm bảo được sự đúng đắn khi sử dụng cơ chế đồng thời khi các giao tác truy xuất cùng 1 đơn vị dữ liệu + với tận dụng thời gian khi mà các giao tác truy cập vào các đơn vị dữ liệu khác
Các thuật toán của môn này ko phải là những lưu đồ mà nó là tập hợp những nguyên tác
An toàn & an ninh dữ liệu
Ý nghĩa: cần phải đảm bảo an toàn & an ninh DL
An toàn: là khắc phục những vấn đề mà người dùng trong hệ thống
An ninh: chống hacker, người bên ngoài hệ thống
An toàn
Các sự cố & hậu quả
Mất hết dữ liệu
Khắc phục:
Backup
Restore
Recovery > redo
(Recovery > restore, redo)
Gây sai sót nội dung.
Nguyên nhân là gì?
Do vi phạm tính tính nguyên tố của giao tác
nguyên nhân sâu xa (chính) gây vi phạm tính nguyên tố của giao tác là do giao tác bị gián đoạn
Có 2 loại gián đoạn:
Gián đoạn giả:
Gia tác đã commit (nghĩa là dữ liệu đã ghi vẫn còn nằm trên buffer chưa thật sự đổ xuống ổ cứng) => nhưng đã commit rồi (nghĩa là nó nghĩ mình đã xong nhưng thật tế thì chưa - tức dữ liệu 1 phần ghi xuống rồi 1 phần thì chưa)
Khắc phục dùng: redo
Gián đoạn thật
Khắc phục dùng: undo
Khắc phục gián đoạn giả & gián đoạn thật với Undo & redo liệu đã đủ chưa?
Ta thiếu 1 cái bổ trợ cho 2 qua trình này
Nhật ký giao tác
(log file)
Các mẫu tin của log file là gì?
là mẫu: Start. rollback, end
Mẫu tin <T,A,v,w> có ý nghĩa là gì?
Điểm kiểm tra (Checkpoint)
Cấu trúc của checkpoint linh động:
<start ckpt (T1, T2,...Tn)>
<end ckpt>
(Tham số T1, T2..Tn này là những giao tác đang còn chạy dỡ dang và cho ta biết là start ckpt này sẽ ghi nhận vào <mẫu tin> và ghi xuống nhật ký lun)
Redo & Undo có nhiệm vụ gì?
Nội dung checkpoint
Câu hỏi ngoài cho môn CSDL:
Thủ tục cũng viết ràng buộc được bên trong, Khi tạo bảng ta cũng viết được rbtv, khi ta create Rule trong sql cũng là RBTV, khi nhập form ta cũng sử lý được ràng buộc toàn vẹn => Vậy viết nhiều RBTV có dư thừa ko? ta nên viết RBTV ở đâu cho hợp lý?????