INFO20003 Database Systems: chấm điểm ra sao và mất điểm ở đâu?

Phần lớn sinh viên chật vật với INFO20003 không phải vì vướng cú pháp SQL. Họ mất điểm ngay ở khâu mô hình hoá dữ liệu, tức là vài ngày trước khi viết dòng SQL đầu tiên, bởi một lược đồ đọc sai đề bài vẫn sẽ cho ra những câu truy vấn chạy trơn tru mà trả lời sai câu hỏi.

Tác giả: Đội ngũ biên tập MAAS · Hiệu đính bởi chuyên gia hướng dẫn của MAAS
Cập nhật: 2026-09-02
Chuyên mục: it-data

Môn INFO20003 gồm những đầu điểm nào, tỷ trọng bao nhiêu?

Trả lời trực tiếp: Handbook của University of Melbourne công bố ba đầu điểm cho INFO20003 Database Systems năm 2026 gồm ba bài tập thực hành mỗi bài 10%, mười bài quiz ngắn có tính giờ mỗi bài 1%, và một bài thi cuối kỳ viết trong 3 giờ theo hình thức mở tài liệu chiếm 60%. Handbook ước tính ba bài tập ngốn 30 tới 35 giờ và cả ba đều làm cá nhân.

Dẫn chứng: Cách chia này quan trọng hơn vẻ ngoài của các con số phần trăm. Riêng bài thi đã chiếm 60%, nên sinh viên nào coi đây là môn ăn điểm bằng bài tập rồi để dồn việc ôn vào hai tuần cuối là đang phó thác hơn một nửa số điểm cho một buổi thi 3 giờ. Mười bài quiz mỗi bài 1% nghe như không đáng kể, nhưng chúng rải đều suốt học kỳ và có chức năng giữ nhịp học chứ không phải để kiếm điểm. Sinh viên bỏ 4 bài quiz thì mất 4 điểm, và mất luôn 4 lần được báo rằng cách hiểu chuẩn hoá của mình đang lệch dần.

Việc cần làm: ngay tuần 1, mở trang assessment trong handbook đúng năm học của bạn chứ không phải một trang chia sẻ ghi chép, rồi ghi ba tỷ trọng và hai ngưỡng hurdle lên trang đầu tập vở. Handbook được lưu theo từng năm, và bản 2018 lẫn bản 2023 của môn này đều khác bản 2026.

Ngưỡng hurdle của bài tập vận hành thế nào?

Trả lời trực tiếp: INFO20003 đặt hai ngưỡng hurdle. Sinh viên phải đạt tối thiểu 50% ở phần bài tập, tức 15 trên 30 điểm, và đồng thời phải đạt tối thiểu 50% cộng gộp giữa bài thi với các bài quiz, tức 35 trên 70 điểm mà hai đầu điểm này chia nhau. Hai ngưỡng được xét tách rời, nên vượt một ngưỡng không bù được cho ngưỡng còn lại.

Dẫn chứng: Hurdle khác về bản chất với tỷ trọng, và sinh viên chưa từng gặp nó thường nhận ra sự khác biệt quá muộn. Với tỷ trọng thuần tuý thì điểm bù trừ được cho nhau, nên thi tốt sẽ gánh phần bài tập yếu. Với hurdle thì không, vì mỗi mốc 50% phải tự nó vượt qua. Sinh viên đang có 13 trên 30 điểm bài tập sẽ không thể qua môn dù thi được bao nhiêu, vì hai ngưỡng được xét tách rời nhau. Cấu trúc hai hurdle ở đây cũng cho thấy các bài quiz không phải để trang trí, bởi chúng nằm chung nhóm 70 điểm với bài thi, nên điểm quiz tích luỹ trong học kỳ thật sự kéo thấp mức điểm bạn cần đạt trong phòng thi.

Ví dụ: Một bạn tìm tới buổi hướng dẫn ở tuần 11 với 12 trên 30 điểm bài tập và dự định "gỡ lại bằng bài thi". Dự định đó không thể thành, và cuộc trao đổi hữu ích hôm ấy không phải về kỹ thuật ôn tập mà về các điều khoản đặc cách và đánh giá lại nằm trong chính trang assessment của môn. Đọc ngưỡng hurdle từ tuần 1 hẳn đã làm bạn ấy chọn ưu tiên khác ở tuần 4.

Bài thi thật sự kiểm tra những nội dung nào?

Trả lời trực tiếp: Nội dung môn học mà handbook công bố trải từ mô hình thực thể quan hệ ở mức khái niệm cho tới thiết kế vật lý, chuẩn hoá và phi chuẩn hoá, mô hình quan hệ và đại số quan hệ, SQL, xử lý và tối ưu truy vấn, giao dịch, tổ chức lưu trữ, quản trị cơ sở dữ liệu, kho dữ liệu và phân tích dữ liệu lớn, kèm phần giới thiệu các hệ NoSQL hiện đại.

Dẫn chứng: Danh sách nội dung mà handbook công bố rất rộng, và việc bài thi cho mở tài liệu làm thay đổi hẳn ý nghĩa của chữ "thuộc bài". Trong một bài thi đóng tài liệu, giới hạn nằm ở trí nhớ. Trong một bài thi mở tài liệu kéo dài 3 giờ, mọi người trong phòng đều có sẵn cú pháp trước mặt, nên điểm phân hoá ở khả năng phán đoán: lược đồ này vi phạm dạng chuẩn nào, một chỉ mục ở đây có thật sự giúp câu truy vấn nhanh hơn không, vì sao một dị thường giao dịch xuất hiện ở mức cô lập này mà không xuất hiện ở mức khác. Năm chuẩn đầu ra của môn cũng cho thấy đúng điều đó, khi chúng yêu cầu sinh viên giải các bài toán mô hình hoá dữ liệu thực tế, thiết kế truy vấn SQL, hiểu cơ chế và chính sách bên trong hệ quản trị, áp dụng giao dịch và lập luận cho việc dùng chúng, rồi đo và tinh chỉnh các truy vấn phân tích. Ba trong năm động từ ấy đòi lập luận chứ không đòi thao tác.

Việc cần làm: dựng một tờ tra cứu sắp theo QUYẾT ĐỊNH chứ không sắp theo chủ đề. Mỗi trang ứng với một câu hỏi bạn có thể bị buộc phải phân xử, gồm quy tắc, phản ví dụ kinh điển, và trường hợp quy tắc ấy không áp dụng được. Tờ giấy sắp theo kiểu "ghi chép chương 5" gần như vô dụng khi bị ép thời gian, còn tờ giấy sắp theo kiểu "làm sao phân biệt 2NF với 3NF" thì không.

Nên làm bài mô hình hoá ER theo trình tự nào?

Trả lời trực tiếp: Đi từ đề bài ra ngoài theo trình tự cố định, gồm thực thể, rồi thuộc tính và khoá, rồi quan hệ cùng bậc của nó, rồi ràng buộc lực lượng và ràng buộc tham gia, và chỉ sau đó mới tới thực thể yếu, phân cấp và gộp. Hãy phác mô hình trước khi mở công cụ cơ sở dữ liệu, vì lỗi mô hình rất rẻ khi còn trên giấy.

Dẫn chứng: Bằng chứng về chỗ người mới hay hỏng thì cụ thể một cách đáng chú ý. Rashkovits và Lavy (2021) phân tích sơ đồ ER của 65 sinh viên năm hai ngành hệ thống thông tin và phân loại từng lỗi theo thang SOLO, và thấy các thất bại dồn vào những cấu trúc trừu tượng chứ không nằm ở phần dễ thấy. Bảy mươi phần trăm người tham gia liệt kê đủ các thực thể mạnh cần có và 75% dựng đúng các quan hệ nhị phân, nhưng 80% bỏ sót một quan hệ ba ngôi bắt buộc, 83% không dựng được phép gộp mà đề bài cần, 86% mô hình hoá sai phần phân cấp, và 88% không đánh dấu một thực thể yếu là yếu. Cách hai tác giả giải thích là những cấu trúc khó chính là những thứ đề bài không hề gọi tên: "Aggregations, hierarchies, and weak entities are not specified in the text at all" (Rashkovits & Lavy, 2021, tr. 15). Hai tác giả nói thẳng rằng thực thể yếu là khái niệm trơn tuột với người thiết kế ở giai đoạn này. Khoảng cách giữa điều đề bài viết ra và điều mô hình phải chứa đựng chính là toàn bộ chỗ khó.

Việc cần làm: sau khi có bản nháp mô hình, hãy chạy một lượt rà riêng chỉ để tìm bốn cấu trúc mà đề bài sẽ không gọi tên. Hãy tự hỏi có thực thể nào không định danh được nếu tách khỏi thực thể cha hay không, có quan hệ nào thật sự cần ba bên tham gia thay vì hai cặp nối tiếp hay không, có cặp thực thể nào chung một thực thể cha hay không, và có quan hệ nào lại tham gia vào một quan hệ khác hay không. Rashkovits và Lavy không ghi nhận sinh viên nào trong mẫu đề xuất lời giải n ngôi ở chỗ lời giải ấy có cơ sở, nên lượt rà này tốn khoảng 20 phút và nhắm đúng nơi điểm đã mất.

Những lỗi SQL nào hay gặp nhất, và vì sao chúng lặp lại?

Trả lời trực tiếp: Các lỗi SQL tái diễn thuộc về logic chứ không thuộc về cú pháp. Lỗi cú pháp làm câu truy vấn dừng lại và tự nó lộ ra, còn lỗi logic trả về một tập kết quả trông hợp lý mà lại đáp cho một câu hỏi khác, và đó là lý do nó sống sót cho tới lúc nộp bài.

Dẫn chứng: Taipalus và cộng sự (2018) phân tích hơn 33.000 câu truy vấn SQL do sinh viên một môn cơ sở dữ liệu nhập môn nộp lên, dựng bảng phân loại lỗi không phụ thuộc hệ quản trị cụ thể, và báo cáo rằng phân tích ấy "reveals new types of errors, namely logical errors recurring in similar manners among different students" (Taipalus và cộng sự, 2018, tr. 1). Từ đáng chú ý ở đây là tái diễn, bởi đây không phải những cái sảy tay ngẫu nhiên mà là cùng một lỗi được các sinh viên khác nhau tái tạo độc lập, và đó là dấu hiệu của một ngộ nhận chung chứ không phải của sự cẩu thả. Miedema và cộng sự (2023) theo đuổi tiếp ý đó bằng một quy trình Policy Delphi hai vòng với 19 chuyên gia SQL để thu thập giả thuyết về nguyên nhân đứng sau từng lỗi, và lập luận rằng nhận diện được ngộ nhận mới cho phép việc dạy chạm vào nguyên nhân thay vì chạm vào triệu chứng. Với sinh viên, hệ quả thực tế là một câu truy vấn chạy được không phải bằng chứng rằng nó đúng.

Ví dụ: Câu truy vấn tổng hợp của một bạn trả về con số trông rất hợp lý cho từng khách hàng mà vẫn bị trừ điểm. Phép nối đã âm thầm loại bỏ mọi khách hàng chưa có đơn nào, nên báo cáo trả lời câu "giá trị trung bình trong nhóm khách đã đặt hàng" trong khi đề bài hỏi giá trị trung bình trên toàn bộ khách hàng. Không có lỗi nào hiện ra cả. Cách sửa chỉ là một từ trong kiểu nối, còn thói quen lẽ ra đã bắt được nó là đối chiếu số dòng kết quả với một tổng đã biết trước khi tin vào đầu ra.

Việc cần làm: hãy kiểm mọi câu truy vấn bằng một thứ bạn đã biết trước. Đếm số dòng của từng bảng gốc, ước lượng thô xem kết quả nên có bao nhiêu dòng, rồi mới chạy. Chỗ nào con số làm bạn ngạc nhiên thì câu truy vấn đang sai kể cả khi các số trông hợp lý, và phép kiểm này tốn chưa tới một phút cho mỗi câu.

Nên rải khối lượng công việc trong học kỳ ra sao?

Trả lời trực tiếp: Hãy coi ba bài tập và mười bài quiz là một lịch trình duy nhất thay vì mười ba sự kiện rời. Chính handbook ước tính ba bài tập tốn 30 tới 35 giờ, tức khoảng 3 giờ mỗi tuần trong học kỳ 12 tuần, và con số ấy chỉ kham nổi nếu bắt đầu từ tuần 1.

Dẫn chứng: Trình tự nội dung của môn mang tính tích luỹ theo kiểu trừng phạt người học dồn. Chuẩn hoá dựa trên một lược đồ quan hệ đúng, mà lược đồ ấy lại dựa trên một mô hình khái niệm đúng, còn tối ưu truy vấn thì phụ thuộc vào việc hiểu bộ xử lý truy vấn dùng các cấu trúc vật lý thế nào. Sinh viên hoãn phần mô hình hoá tới lúc sắp hạn nộp bài tập thứ hai là đang cố học ba lớp phụ thuộc nhau trong cùng một tuần, và các bài quiz hằng tuần thì đã ghi nhận độ lệch ấy từ trước. Vì các bài quiz nằm chung nhóm 70 điểm với bài thi, độ lệch đó hiện rõ trên sổ điểm từ rất lâu trước kỳ thi.

Việc cần làm: sau mỗi bài quiz, viết một dòng nêu bạn sai chỗ nào và chỗ đó thuộc lớp kiến thức nào. Ba dòng cùng chỉ về một lớp là tín hiệu để bạn tìm người hỗ trợ ngay tuần đó, thay vì đợi tới tuần ôn thi.

Câu hỏi thường gặp

INFO20003 có phải cùng một môn ở mọi trường Úc không?
Không. INFO20003 với tên Database Systems là môn của University of Melbourne, được xếp là môn cốt lõi trong chương trình Bachelor of Science ở hai chuyên ngành Computing and Software Systems và Informatics, đồng thời bắt buộc trong Diploma in Informatics. Các mã bắt đầu bằng INFO được dùng rất rộng khắp ngành cho những môn không liên quan gì nhau, nên hãy đối chiếu mã với handbook của chính trường bạn trước khi mua giáo trình hay tải ghi chép.

Thi mở tài liệu thì có nghĩa là không cần thuộc gì phải không?
Không. Mở tài liệu chỉ gỡ bỏ áp lực trí nhớ chứ không gỡ áp lực thời gian. Trong 3 giờ bạn không thể tra cứu thứ mình chưa từng đọc, nên nội dung vẫn phải đủ quen để việc tra cứu là xác nhận lại chứ không phải học mới.

Nếu tôi trượt ngưỡng hurdle của bài tập nhưng các phần khác đều đạt thì sao?
Ngưỡng hurdle là một điều kiện tách rời khỏi điểm tổng có trọng số, nên trượt nó là trượt môn bất kể kết quả thi. Nếu bạn đang trong vùng rủi ro thì trang assessment của đúng năm học và giảng viên phụ trách môn là hai nơi cần liên hệ trước tiên, và tuần 8 là thời điểm nêu chuyện này tốt hơn hẳn tuần 12.

MAAS có viết hộ bài tập cơ sở dữ liệu hay script SQL không?
Không. MAAS làm việc với vai trò cố vấn học thuật theo chuẩn liêm chính học thuật của Úc, và phần bài bạn nộp phải do chính bạn làm. Chuyên gia của MAAS có thể giúp bạn đọc đề cho đúng, kiểm xem mô hình ER của bạn có đứng vững trước các yêu cầu hay không, và cùng bạn lần ra vì sao một câu truy vấn trả về kết quả như vậy, giống hệt cách một buổi tư vấn với trợ giảng diễn ra.

Tôi có cần kinh nghiệm lập trình trước khi học môn này không?
Không cần theo nghĩa thông thường. Môn này nói về mô hình hoá dữ liệu và quản trị cơ sở dữ liệu chứ không nói về lập trình tổng quát, nên sinh viên đi lên từ nền lập trình thường thấy phần mô hình hoá khó hơn phần SQL, còn sinh viên đi lên từ nền kinh doanh lại thấy ngược lại.

References

Miedema, D., Fletcher, G., & Aivaloglou, E. (2023). Expert perspectives on student errors in SQL. ACM Transactions on Computing Education, 23(1), 1–28. https://doi.org/10.1145/3551392

Rashkovits, R., & Lavy, I. (2021). Mapping common errors in entity relationship diagram design of novice designers. International Journal of Database Management Systems, 13(1), 1–19. https://doi.org/10.5121/ijdms.2021.13101

Taipalus, T., Siponen, M., & Vartiainen, T. (2018). Errors and complications in SQL query formulation. ACM Transactions on Computing Education, 18(3), 1–29. https://doi.org/10.1145/3231712

Tools & resources

• Hỗ trợ học thuật MAAS để nhận nhận xét cho mô hình dữ liệu hoặc bản nháp bạn đã viết.
• Gia sư MAAS để cùng chuyên gia đi qua phần chuẩn hoá và logic truy vấn.