Please enable JavaScript.

Coggle requires JavaScript to display documents.

Hệ quản trị - cơ sở dữ liệu - Coggle Diagram

- - - - 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 )
- - - - 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)
    - - Input
        
        Output
        
        Read
        
        Write
    - - Begin => Committed => Rollback/ abort ...blabla
  - - - Lịch tuần tự
      - Lịch đồng thời
    - - 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!
    - - 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
- - - - 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?
  - - - 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 =))
    - - 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
- - - - Mục đích của nó là để biết T nào trước T nào sau
    - - 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ấ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
    - - 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)