Hãy hình dung một tình huống giảng dạy: bạn muốn tìm những sinh viên chưa nộp bài, bèn nhờ AI viết một đoạn SQL. Chương trình chạy trơn tru, trên màn hình hiện ra một danh sách gọn gàng.
Không có báo lỗi, tên cột cũng khớp. Bạn đang chuẩn bị gửi lời nhắc thì phát hiện một sinh viên hoàn toàn không có bản ghi nộp bài lại không xuất hiện trong kết quả.
Vấn đề có thể nằm trong cách nối bảng. Truy vấn chỉ giữ lại những bản ghi khớp được ở cả hai bảng, còn "người chưa có bản ghi nào" ngay từ đầu đã bị loại ra ngoài.
Kiểu lỗi này rất lặng lẽ. Cơ sở dữ liệu đã hoàn thành đúng những thao tác bạn viết, điều thực sự cần kiểm tra là những thao tác ấy có diễn đạt đúng ý bạn ban đầu hay không.
Môn DSAI2202 《Database Principles》(Nguyên lý cơ sở dữ liệu) của Đại học Bách khoa Hồng Kông (PolyU) đề cập đến mô hình hóa dữ liệu, SQL, quản lý giao dịch và bảo mật cơ sở dữ liệu. Bước vào khóa học với câu hỏi kiểu "vì sao kết quả thiếu mất một người", những khái niệm trừu tượng bỗng có manh mối để lần theo. Mô tả khóa học chính thức của PolyU
Trong danh sách không có bạn ấy: không có bản ghi, hay không có người này?
Trước hết hãy thu nhỏ ví dụ ở phần mở đầu.
Bảng sinh viên có ba người: A Minh, Tiểu Hân, A Kiệt. Bảng nộp bài chỉ có bản ghi của A Minh và Tiểu Hân, A Kiệt chưa nộp.
Nếu trước tiên dùng inner join để ghép hai bảng rồi mới tìm sinh viên "chưa nộp bài", A Kiệt đã không còn trong kết quả trung gian. Các bước lọc về sau dù kỹ đến đâu cũng không tìm lại được một người đã bị loại từ trước.
Một hướng suy nghĩ là xuất phát từ danh sách sinh viên đầy đủ, giữ lại từng sinh viên, rồi kiểm tra xem có bản ghi nộp bài tương ứng hay không. Phép left join có thể giúp diễn đạt quan hệ này, nhưng vẫn cần tiếp tục đối chiếu phạm vi bài tập, trường dùng để khớp và các điều kiện lọc tiếp theo. Đổi sang một từ khóa join không tự động bảo đảm câu trả lời đúng. Hướng dẫn chính thức về join của PostgreSQL
Trong Lab 7: Suy luận xuyên quan hệ của EvoClass, người học đối chiếu danh sách đăng ký của sinh viên với danh sách trên nền tảng học tập, quan sát cách các kiểu join khác nhau giữ lại hoặc loại bỏ bản ghi.
Điều đáng luyện ở đây là nói rõ trước khi viết truy vấn: một dòng trong kết quả đại diện cho ai? Những người nào bắt buộc phải được giữ lại? Khi không tìm thấy bản ghi khớp thì điều đó có nghĩa là gì?
Có được vài câu như vậy, SQL mới có một mục tiêu để đối chiếu.
Trước khi truy vấn, hãy quyết định cách ghi nhận thế giới
Tiếp tục nhìn vào danh sách này. Một sinh viên có thể chọn nhiều môn học, một môn học có thể có nhiều bài tập, mỗi bài tập lại có thể cho phép nộp nhiều lần.
Nếu nhồi tất cả vào một bảng lớn, tên sinh viên, tên môn học và thông tin giảng viên có thể lặp đi lặp lại. Sửa một chỗ, những chỗ khác vẫn còn giá trị cũ; khi thống kê số sinh viên, lại có thể đếm trùng cùng một người.
Lúc này, vấn đề đã xảy ra trước cả khi truy vấn: mỗi dòng trong bảng rốt cuộc đang ghi nhận điều gì?
Lab 2: Từ thế giới thực đến bảng dữ liệu PostgreSQL đi từ vấn đề dư thừa và cập nhật của bảng phẳng để bước vào thiết kế cơ sở dữ liệu quan hệ, còn Lab 9: Chuẩn hóa bảng đăng ký thì đi sâu hơn vào chuẩn hóa.
Có thể bắt đầu bằng một bài tập nhỏ trên giấy: viết "sinh viên", "môn học", "quan hệ chọn môn" lên ba tờ giấy riêng, rồi giải thích chúng nối với nhau thế nào. Một sinh viên chuyển ngành thì cần sửa ở đâu? Một môn học mới chưa có ai chọn thì có thể ghi nhận trước được không?
Những câu hỏi dồn ép này khiến cấu trúc dữ liệu phải chịu sự kiểm tra của những thay đổi thường ngày. Việc tách bảng có hợp lý hay không phải xem nó có diễn đạt rõ quan hệ và giữ được tính nhất quán khi sửa đổi hay không.
Quay lại truy vấn ở phần đầu, bạn cũng sẽ dễ phán đoán hơn: vài dòng dư ra trước mắt là vài sinh viên khác nhau, hay là vài lần nộp bài của cùng một sinh viên?
Một câu lệnh đúng, cả thao tác vẫn có thể mới hoàn thành một nửa
Sau khi tra ra kết quả, hệ thống thường còn phải sửa dữ liệu.
Chẳng hạn, một sinh viên xin đổi lớp, cần được rút khỏi lớp cũ rồi thêm vào lớp mới. Nếu bước thứ nhất đã lưu, còn bước thứ hai vì lý do nào đó thất bại, sinh viên có thể tạm thời không thuộc lớp nào. Nhìn riêng từng câu lệnh, cả hai đều có thể viết đúng; nhìn tổng thể, hệ thống lại để lại một trạng thái không trọn vẹn.
Giao dịch (transaction) mang đến công cụ cơ bản cho vấn đề này: tổ chức những bước cần hoàn thành cùng nhau thành một chỉnh thể, để chúng được commit như một khối, hoặc bị hủy khi thất bại. Việc xác định "chỉnh thể" ấy vẫn cần hiểu nhiệm vụ cụ thể. Hướng dẫn chính thức về giao dịch của PostgreSQL
Thí nghiệm về giao dịch và đồng thời trong Lab 10 đưa chủ đề tiến tới ranh giới giao dịch và điều khiển đồng thời, lấy bối cảnh xử lý số chỗ tại quầy đăng ký chọn môn, quan sát điều gì xảy ra khi hai phiên thao tác cùng lúc.
Khi luyện tập, có thể chủ động tạo một lần thất bại giữa hai bước thao tác, rồi xem cơ sở dữ liệu thực sự để lại những gì. Tiếp đó cho hai phiên cùng thao tác trên một phần dữ liệu, quan sát xem những bước vốn trơn tru còn đúng hay không.
Một thí nghiệm nhờ vậy có thêm một tầng ý nghĩa: ngoài việc thấy mọi thứ thành công ra sao, cũng cần biết nó sẽ thất bại thế nào.
Sau khi nhờ AI viết SQL, bạn tự chịu trách nhiệm kiểm chứng điều gì?
Có những trải nghiệm phía trên rồi, khi nhìn lại truy vấn do AI đưa ra, trọng tâm chú ý sẽ thay đổi.
Danh sách thiếu người ở phần đầu có thể kiểm tra bằng ba bản ghi sinh viên hư cấu; vấn đề đếm trùng có thể kiểm tra bằng cách thêm một sinh viên có hai lần nộp bài; thao tác đổi lớp thì có thể kiểm tra trạng thái dữ liệu khi thất bại giữa chừng.
Những ví dụ nhỏ này là căn cứ để phán đoán. Một lời giải thích trôi chảy không thể thay thế việc đối chiếu kết quả.
Lab 12: Kiểm chứng SQL do AI tạo ra đưa việc rà soát vào bài luyện: nó chạy được không? Nó trả lời đúng câu hỏi không? Nó có thể phá hỏng điều gì? Ai có quyền chạy nó?
Người học có thể lần theo một nhiệm vụ cụ thể mà hỏi tiếp từng bước: truy vấn này giữ lại những bản ghi nào? Thao tác sửa sẽ ảnh hưởng đến bao nhiêu dòng? Nếu dự kiến chỉ sửa một người, làm sao phát hiện phạm vi bị viết sai trước khi thực thi? Công cụ có quyền sửa đổi liệu có đồng nghĩa nhiệm vụ hiện tại cho phép nó làm như vậy?
Với những người đang làm quen với cơ sở dữ liệu quan hệ, hoặc đã bắt đầu nhờ AI viết truy vấn, cổng vào khóa DSAI2202 trên EvoClass cung cấp một lộ trình tiếp tục đi sâu từ các thao tác cơ bản. Có thể chuẩn bị trước một bộ dữ liệu nhỏ mà bạn tự kiểm tra được bằng tay, rồi bước vào phần luyện với kết quả kỳ vọng trong đầu.
Lần tới khi trên màn hình hiện ra một danh sách gọn gàng, hãy tìm trước xem ai là người dễ bị bỏ sót nhất.
Giải thích được vì sao người ấy xuất hiện, vì sao người ấy vắng mặt, bạn mới bắt đầu biết câu trả lời này có đáng tin hay không.
Định vị khóa học dựa trên mô tả khóa học chính thức của PolyU, phần giới thiệu các lab dựa trên tài liệu hiện hành của EvoClass. Các liên kết bài học trong bài trỏ tới tài liệu học tập tiếng Trung giản thể. Các tình huống danh sách, nộp bài và đổi lớp đều là ví dụ giảng dạy được dựng nên để giúp hiểu khái niệm, không phải ca sinh viên hay ghi nhận hiệu quả sử dụng.