COMM2822 Databases for Business Analytics: điểm nằm ở đâu?

Trả lời thẳng: COMM2822 Databases for Business Analytics (tên đầy đủ là Introduction to Databases for Business Analytics) là môn đại học 6 unit of credit của UNSW Business School, do School of Information Systems and Technology Management phụ trách. Handbook 2026 mô tả môn học về cơ sở dữ liệu kinh doanh, SQL cùng các nguyên lý và đặc điểm của Big Data, mở ở Term 1 và Term 2.

Handbook nêu rằng sinh viên "will learn the Structured Query Language (SQL) language and how to use it to access data stored in relational database system, including fetch, delete, insert, and modify data" (UNSW Sydney, n.d.). Cùng mục đó đặt ra năm course learning outcome (CLO), đi từ phương pháp mô hình hoá khái niệm và quan hệ ở CLO1 đến các hệ quả về đạo đức, quyền riêng tư và an ninh của Big Data ở CLO5. Vì CLO2 yêu cầu bạn "Design, implement and evaluate database systems" (UNSW Sydney, n.d.), chữ evaluate cho thấy việc biện minh cho thiết kế của chính mình là một phần của đề bài.

Lịch sử mã của COMM2822 Databases for Business Analytics có ý nghĩa khi đăng ký học. COMM2822 trước đây mang mã COMM1822, và sinh viên đã hoàn thành COMM1822 không thể đăng ký mã mới, nên hãy kiểm tra hồ sơ của bạn trước khi tìm ghi chú cũ. Ai muốn làm quen với ngôn ngữ này có thể bắt đầu từ bài tổng quan về SQL, còn phần dữ liệu của CLO5 nằm trong bài về Big data. Các bài đánh giá, trọng số và ngày nộp thay đổi giữa các kỳ, nên hãy lấy chúng từ course outline trên Moodle chứ không lấy từ một bài blog.

Trả lời thẳng: Course outline của kỳ bạn học quy định các bài đánh giá, trọng số và ngày nộp, nên hãy xác nhận ở đó. Số liệu lỗi đã công bố cho thấy điểm ER mất ở đâu: Rashkovits và Lavy (2021) ghi nhận 88% trong 65 sinh viên bỏ sót weak entity và 83% bỏ sót reflexive relationship, trong khi entity cơ bản và khoá thì phần lớn làm đúng.

Rashkovits và Lavy (2021) lập bản đồ lỗi trong nghiên cứu của họ về các sơ đồ làm trong kỳ thi cuối kỳ, và phần tóm tắt của họ viết rằng "novice designers encounter difficulties in understanding and implementing such models" (Rashkovits & Lavy, 2021). Độ khó phân bố không đều. Những construct đơn giản phần lớn được làm tốt: 45 sinh viên (70%) vẽ đủ mọi strong entity, 48 sinh viên (75%) đúng toàn bộ binary relationship, 50 sinh viên (79%) có đủ attribute và 54 sinh viên (84%) chọn đúng khoá.

Nguồn: Rashkovits và Lavy (2021), bài ERD trong kỳ thi cuối kỳ, 65 sinh viên.

Chỉ có 11 sinh viên (17%) xử lý đúng reflexive relationship và 13 sinh viên (20%) xử lý đúng ternary relationship, còn 32 sinh viên thay một ternary relationship bằng hai binary relationship, làm mất thông tin rằng ba đối tượng cùng tham gia một lúc. Thêm 20 sinh viên (31%) tự thêm những entity mà tình huống không hề yêu cầu, và 17 người trong số đó thêm "Movie Series". Hãy chuẩn bị mất điểm ở những mối quan hệ mà tình huống ngụ ý nhưng không gọi tên, chứ không phải ở việc vẽ các ô. Bài về mô hình entity-relationship liệt kê các construct này.

Trả lời thẳng: Đọc tình huống để tìm danh từ cần một bảng riêng và động từ nối chúng, quyết định từng cardinality và ghi giả định đứng sau nó. Biến mọi liên kết nhiều-nhiều thành một bảng riêng, rồi gọi tên anomaly mà mỗi lần tách bảng loại bỏ.

Khoảng trống thứ hai là một ca mơ hồ có ghi lại các quyết định. Lấy một câu từ một tình huống tưởng tượng: "Mỗi sản phẩm được mua từ một nhà cung cấp." Ở Design A, bảng Product chứa supplier_id, nên một Supplier liên kết với nhiều Product. Ở Design B, một bảng Supply riêng nối Product với Supplier kèm ngày bắt đầu và đơn giá, nên một sản phẩm có thể đổi nhà cung cấp theo thời gian. Hãy hỏi câu của người quản lý: "chúng ta đã trả Supplier X bao nhiêu cho sản phẩm P hồi tháng Ba năm ngoái?" Design A không trả lời được khi nhà cung cấp đã đổi, còn Design B trả lời được, với giá là thêm một bảng và thêm một phép join. Cả hai thiết kế đều không sai, và điểm thuộc về báo cáo nêu giả định của mình ngay cạnh sơ đồ. Ví dụ này là minh hoạ do MAAS viết, không phải ca nghiên cứu của UNSW.

Chuẩn hoá cơ sở dữ liệu là chỗ lời giải thích ăn điểm. Kent (1983) viết rằng "The normalization rules are designed to prevent update anomalies and data inconsistencies" (Kent, 1983). Ví dụ của ông lưu WAREHOUSE-ADDRESS trong một bản ghi có khoá là PART và WAREHOUSE, gây ra 4 vấn đề: địa chỉ bị lặp, mọi bản sao phải đổi khi kho dời chỗ, các bản sao có thể mâu thuẫn, và một kho trống không có chỗ để lưu địa chỉ. Ông bổ sung rằng "There is no obligation to fully normalize all records when actual performance requirements are taken into account" (Kent, 1983), nên nếu dừng ở dạng chuẩn ba, hãy nói rõ vì sao.

Trả lời thẳng: Viết câu hỏi kinh doanh thành một câu thường ngay phía trên mỗi truy vấn, rồi chạy truy vấn trên một bảng bạn tự đếm bằng tay được. Ahadi và cộng sự (2016) thấy phần lớn lỗi ngữ nghĩa là lỗi bỏ sót trong các truy vấn cần JOIN, subquery hoặc GROUP BY, nên hãy thử các truy vấn đó trước.

Ahadi và cộng sự (2016) nghiên cứu hơn 160.000 bản chụp truy vấn của hơn 2300 sinh viên trong chín năm và báo cáo rằng "the majority of semantic mistakes are of the type 'omission'" (Ahadi et al., 2016). Taipalus và cộng sự (2018) phân tích hơn 33.000 truy vấn của 237 sinh viên và xếp các lỗi và rắc rối vào 18 nhóm, đánh số tới 105. Khoảng 59% trong 158 sinh viên dùng GROUP BY sai ở một bài tập, một truy vấn mà SQLite chấp nhận không phàn nàn, và khoảng 45% trong 152 sinh viên không dùng DISTINCT ở chỗ cần nó ở một bài khác. Brass và Goldberg (2006) lập một danh sách các lỗi ngữ nghĩa trong truy vấn SQL, loại lỗi mà cơ sở dữ liệu không báo. Những lỗi làm mất điểm là những lỗi mà cơ sở dữ liệu không báo.

Phép thử năm truy vấn với join và COUNT

Khoảng trống thứ ba là một phép thử cho ra kết quả sai. MAAS dựng 3 sản phẩm (Desk, Lamp, Chair) và 3 dòng đơn hàng trong SQLite, trong đó Chair chưa từng được đặt, rồi hỏi "mỗi sản phẩm có bao nhiêu dòng đơn hàng?" Năm phiên bản truy vấn cho năm kết quả khác nhau, và chỉ phiên bản thứ ba khớp với câu hỏi.

Nguồn: thử nghiệm của MAAS với hai bảng product và order_line 3 dòng trong SQLite, chạy ngày 2026-10-27. Hãy chạy lại trên Oracle SQL.

COUNT trên một cột bỏ qua giá trị null mà left join tạo ra, còn COUNT(*) thì không, vì vậy Chair hiện 1 ở dòng thứ hai. Bộ lọc WHERE lại loại dòng không khớp một lần nữa, nên hãy đặt điều kiện trong mệnh đề ON. Bài về giá trị null giải thích lý do. Để xem cách một trường khác chấm cơ sở dữ liệu, hãy đọc hướng dẫn INFO20003 Database Systems.

Trả lời thẳng: Ba giả định đáng được kiểm tra: dữ liệu công khai thì dùng tự do, an ninh là việc của đội IT, và Big Data là trung lập. CLO5 yêu cầu bạn thảo luận các hệ quả về đạo đức, quyền riêng tư và an ninh, nên báo cáo cần những hệ quả thiết kế cụ thể chứ không phải một đoạn chung chung về đạo đức.

UNSW dạy ở Úc, nên Privacy Act 1988 là tài liệu tham chiếu tự nhiên cho một tình huống trong nước. Về giả định thứ nhất, Office of the Australian Information Commissioner (OAIC) viết rằng "Where personal information is publicly available on the internet, that does not allow it to be collected and used in whatever way the APP entity chooses without regard to the knowledge and reasonable expectations of the person whose information it concerns" (OAIC, 2026). Về giả định thứ hai, các lựa chọn về cột, vai trò truy cập và xoá dữ liệu chính là biện pháp an ninh, nên hãy mô tả chúng.

Về giả định thứ ba, boyd và Crawford (2012) nêu sáu provocation và lập luận rằng "it is necessary to critically interrogate its assumptions and biases" (boyd & Crawford, 2012). Hãy nói rõ bộ dữ liệu của bạn bỏ sót điều gì. Đây là thông tin chung, không phải tư vấn pháp lý. Hướng dẫn COMM3050 bàn về lạm dụng dữ liệu.

Nguồn: hướng dẫn OAIC (2026) chương 3 và boyd và Crawford (2012), đọc ngày 2026-10-27.