COMM2822: vì sao cơ sở dữ liệu chạy được mà vẫn mất điểm?

COMM2822 Introduction to Databases for Business Analytics ở UNSW là một trong số ít môn kinh doanh mà bài làm hoặc chạy được hoặc không, và chính sự rành mạch đó đánh lừa người học. Lược đồ nạp lên trơn tru, câu truy vấn trả về đúng số dòng, không có gì hỏng, vậy mà điểm vẫn dừng ở khoảng giữa. Lý do là môn này không chấm xem cơ sở dữ liệu của bạn có hoạt động hay không. Nó chấm xem những quyết định thiết kế phía sau có đứng vững khi đối chiếu với bản mô tả nghiệp vụ bạn nhận hay không, và câu truy vấn của bạn có trả lời đúng câu hỏi được đặt ra hay không. Dưới đây là cách các mentor MAAS đọc một môn được thiết kế như vậy, và những chỗ sinh viên Việt Nam ở UNSW hay đánh rơi điểm mà lẽ ra đã kiếm được, dựa trên đúng chiều chất lượng mà Moody và Shanks (2003) tách khỏi tính đúng kỹ thuật.

Tác giả: Ban biên tập MAAS · Hiệu đính bởi mentor chuyên môn của MAAS
Cập nhật: 17/08/2026
Chuyên mục: communication-pr

COMM2822 là môn gì và nằm ở đâu trong chương trình?

Trả lời trực tiếp: COMM2822 Introduction to Databases for Business Analytics là môn 6 tín chỉ của UNSW Business School, do School of Information Systems and Technology Management giảng dạy. Môn dạy các khái niệm, kỹ thuật để tạo lập và quản lý cơ sở dữ liệu doanh nghiệp, cùng nguyên lý dữ liệu lớn và SQL. Đây là môn nền cho nhánh phân tích dữ liệu trong chương trình kinh doanh chứ không phải môn khoa học máy tính.

Bằng chứng: Môn có năm chuẩn đầu ra công bố, và ba chuẩn đầu xếp theo một trình tự có chủ đích, gồm tạo lập và vận dụng phương pháp mô hình hoá ở mức khái niệm lẫn mức quan hệ, rồi thiết kế, triển khai và đánh giá hệ cơ sở dữ liệu, rồi truy xuất và thao tác dữ liệu bằng SQL. Động từ ở chuẩn thứ hai là chỗ người học hay lướt qua. Đánh giá không đồng nghĩa với xây dựng, và một môn yêu cầu bạn đánh giá chính thiết kế của mình là môn đang báo trước rằng phần lập luận có điểm. Hai chuẩn còn lại nói về làm việc nhóm hiệu quả và về các hệ quả đạo đức, quyền riêng tư cùng an ninh của dữ liệu lớn, mà cả hai đều dễ bị quên đúng vì chúng nằm cuối danh sách.

Ví dụ: Một bạn nữ người Việt học năm hai ở UNSW tìm tới MAAS vì bài của bạn bị chấm thấp hơn bài của người cùng lớp, trong khi hai cơ sở dữ liệu có y hệt các bảng như nhau. Khi mentor đặt hai bài cạnh nhau, khác biệt nằm gọn trong nửa trang: bạn kia có một đoạn ngắn giải thích vì sao một mối quan hệ được mô hình hoá thành nhiều-nhiều, còn bạn thì chỉ vẽ ra. Cấu trúc giống nhau. Chỉ một trong hai bài có lập luận, đúng chiều chất lượng mà Moody và Shanks (2003) tách riêng khỏi tính đúng kỹ thuật.

Điểm của một bài cơ sở dữ liệu thực ra nằm ở đâu?

Trả lời trực tiếp: Với một môn thiết kế theo kiểu này, điểm dồn vào ba chỗ, và không chỗ nào là "bài có chạy không". Điểm nằm ở mức độ mô hình bám sát bản mô tả nghiệp vụ, ở phần lập luận cho những giả định bạn buộc phải đưa ra ở những chỗ bản mô tả không nói tới, và ở chỗ câu SQL trả lời đúng câu hỏi được nêu chứ không phải một câu hỏi gần giống mà dễ viết hơn. Đúng kỹ thuật là vé vào cửa, không phải thành tích, đúng ba chiều tính đúng, tính đầy đủ và mức dễ hiểu mà Moody và Shanks (2003) tách bạch khỏi nhau.

Bằng chứng: Các nghiên cứu thực nghiệm về chất lượng mô hình dữ liệu từ lâu đã tách bạch tính đúng với chất lượng, và lập luận rằng một mô hình phải được đánh giá theo nhiều chiều như tính đầy đủ, tính toàn vẹn và mức dễ hiểu, chứ không phải đối chiếu với một đáp án duy nhất (Moody & Shanks, 2003). Đó đúng là logic mà một bảng tiêu chí chấm cơ sở dữ liệu áp dụng. Một mô hình nhất quán bên trong vẫn có thể là bản mô tả tồi cho chính doanh nghiệp mà nó lẽ ra phải mô tả.

Ví dụ: Một bạn nam mô hình hoá tình huống một cửa hàng bán lẻ nhỏ và dựng ra lược đồ mười một bảng, chuẩn hoá rất đẹp. Mentor chỉ hỏi một câu: câu nào trong đề bài khiến em tạo bảng liên hệ nhà cung cấp? Bạn tìm mãi không ra. Bạn đã mô hình hoá cái doanh nghiệp trong tưởng tượng của mình thay vì cái doanh nghiệp đề bài đưa, và mỗi bảng thừa là một chỗ để mất điểm chứ không phải để kiếm điểm.

Vì sao phần giả định lại nặng ký tới vậy?

Trả lời trực tiếp: Bởi mọi tình huống nghiệp vụ giao cho sinh viên đều thiếu thông tin, và thiếu một cách có chủ đích. Mô tả nghiệp vụ ngoài đời vốn mơ hồ, còn môn học đang rèn cho bạn nhận ra chỗ mơ hồ thay vì lấp liếm nó. Khi đề bài không nói một khách hàng có được giữ nhiều tài khoản hay không, bạn buộc phải chọn, và điểm đến từ chỗ bạn nêu rõ lựa chọn cùng hệ quả của nó, chứ không phải từ chỗ bạn chọn trúng phương án người chấm đang nghĩ trong đầu. Một giả định không nói ra thì người đọc hiểu là bạn sơ sót. Một giả định nói ra thì người đọc hiểu là bạn có phán đoán, đúng tinh thần biểu diễn để bàn bạc mà Chen (1976) đặt ra cho ký pháp thực thể liên kết ngay từ đầu.

Bằng chứng: Mô hình thực thể liên kết ra đời như một cách biểu diễn góc nhìn về thế giới thực dưới dạng có thể đem ra bàn bạc và thống nhất trước khi triển khai, đúng tinh thần câu Chen viết: "the entity-relationship model adopts the more natural view that the real world consists of entities and relationships" (Chen, 1976, p. 9). Chữ bàn bạc ở đây quan trọng. Ký pháp tồn tại để một thiết kế có thể bị chất vấn bởi người không ở trong đầu bạn, mà đó chính là việc người chấm đang làm.

Ví dụ: Hai bạn cùng một lớp bài tập xử lý cùng một chỗ mơ hồ theo hai hướng ngược nhau. Một bạn cho phép một lượt đặt phòng tham chiếu tới nhiều phòng, bạn kia thì không. Cả hai đều được điểm tốt, vì cả hai đều viết một câu nói rõ chi tiết nào trong đề bài đẩy mình theo hướng đó và điều gì sẽ phải thay đổi nếu giả định hoá ra sai. Một bạn thứ ba chọn giống bạn đầu tiên nhưng không viết gì cả, và mất đúng phần điểm hai bạn kia giữ được, phần điểm gắn với đúng thứ mà Kent (1983) gọi là xử lý một loại rắc rối cụ thể chứ không phải đạt một cái nhãn chung chung.

Chuẩn hoá thực chất đang kiểm tra điều gì?

Trả lời trực tiếp: Chuẩn hoá kiểm tra xem bạn có gọi tên được vấn đề mà một thay đổi thiết kế giải quyết hay không. Dạng chuẩn thứ ba không phải thứ trang trí gắn vào lúc cuối, nó là một chuỗi quyết định loại bỏ những bất thường cụ thể khi cập nhật, thêm và xoá dữ liệu. Nếu bạn nói được một phép tách bảng đã loại bất thường nào, tức là bạn hiểu. Nếu bạn chỉ nói được các bảng đã đạt 3NF, tức là bạn đọc thuộc một kết quả chứ chưa cho thấy một quá trình.

Bằng chứng: Mô hình quan hệ được đề xuất để người dùng không phải biết dữ liệu được tổ chức vật lý ra sao, và để cấu trúc logic giữ được sự ổn định khi dữ liệu thay đổi (Codd, 1970). Các dạng chuẩn sau đó được trình bày như những quy tắc thực hành nhằm loại bỏ dư thừa và các bất thường do dư thừa gây ra, và bản diễn giải kinh điển bằng lời thường nhấn mạnh rằng mỗi dạng chuẩn xử lý một loại rắc rối riêng chứ không phải một dấu hiệu chất lượng chung chung (Kent, 1983). Một thiết kế có thể chuẩn hoá đầy đủ mà vẫn sai với doanh nghiệp, và đó là lý do phần lập luận nặng ký hơn cái nhãn.

Ví dụ: Một bạn viết trong báo cáo rằng các bảng của bạn đạt 3NF vì bạn đã loại bỏ phụ thuộc bắc cầu. Mentor đề nghị bạn chỉ ra một cái. Bạn lần lại, phát hiện rằng lưu mã bưu chính chi nhánh cạnh tên chi nhánh trong bảng giao dịch nghĩa là mỗi lần chi nhánh chuyển địa điểm sẽ phải cập nhật hàng trăm dòng, rồi viết đúng câu đó vào báo cáo. Phần kỹ thuật không đổi chút nào. Câu văn đó đáng giá phần điểm mà cái nhãn kia không mang lại, đúng sự ổn định logic mà Codd (1970) đặt ra làm mục tiêu cho mô hình quan hệ ngay từ đầu.

Các dạng chuẩn và ký pháp bạn sẽ gặp trong môn này

Trả lời trực tiếp: Đề bài thường nhắc bốn dạng chuẩn bằng tên viết tắt mà không giải thích lại. 1NF đòi mỗi ô chỉ chứa một giá trị đơn, 2NF loại bỏ phụ thuộc từng phần vào một phần khoá chính, còn 3NF loại bỏ phụ thuộc bắc cầu giữa các cột không phải khoá (Kent, 1983). BCNF siết chặt hơn 3NF khi có nhiều khoá ứng viên chồng lấn nhau (Codd, 1974).

Đề bài và slide bài giảng thường nhắc các dạng chuẩn bằng tên viết tắt mà không giải thích lại, nên đáng để nắm trước ý nghĩa của từng cái.

Dạng chuẩn thứ nhất, viết tắt 1NF, đòi mỗi ô chỉ chứa một giá trị đơn. Dạng chuẩn thứ hai, 2NF, loại bỏ phụ thuộc từng phần vào một phần của khoá chính. Dạng chuẩn thứ ba, 3NF, loại bỏ phụ thuộc bắc cầu giữa các cột không phải khoá, đúng như Kent (1983) mô tả riêng cho từng dạng. Dạng chuẩn Boyce-Codd, viết tắt BCNF, siết chặt hơn 3NF cho những trường hợp có nhiều khoá ứng viên chồng lấn nhau (Codd, 1974). Về ký pháp vẽ sơ đồ, hai chuẩn phổ biến nhất là ký pháp Chen gốc dùng hình thoi cho mối quan hệ (Chen, 1976), và ký pháp Crow's Foot dùng ba nhánh chân gà để biểu diễn lực lượng, quen thuộc hơn với hầu hết công cụ vẽ sơ đồ hiện đại.

Làm sao để SQL không trả lời nhầm câu hỏi?

Trả lời trực tiếp: Hãy viết câu hỏi bằng tiếng Việt hoặc tiếng Anh thường phía trên mỗi câu truy vấn trước khi viết truy vấn, rồi đọc ngược kết quả đối chiếu với câu đó. Phần lớn câu SQL làm mất điểm đều đúng cú pháp. Chúng hỏng vì một phép nối âm thầm loại bỏ những dòng không có bản ghi khớp, vì một hàm gộp được tính trên tập đã lọc nên không còn đại diện cho tổng thể mà đề hỏi, hoặc vì một điều kiện được đặt sau bước gom nhóm trong khi đáng lẽ phải đặt trước. Đây là lỗi suy luận, và chúng không bị lộ ra khi chạy thử đúng vì câu truy vấn vẫn trả kết quả bình thường, đúng khoảng cách giữa cú pháp và ngữ nghĩa mà Elmasri và Navathe (2016) dành hẳn nhiều chương để tách bạch.

Bằng chứng: Các giáo trình cơ sở dữ liệu chuẩn coi khâu đặt câu truy vấn là một hoạt động mô hình hoá đúng nghĩa chứ không phải khâu dịch máy móc, và dành nhiều dung lượng cho khác biệt ngữ nghĩa giữa các loại phép nối cũng như cho vị trí đặt điều kiện lọc trong trình tự tính toán (Connolly & Begg, 2015; Elmasri & Navathe, 2016). Những chương đó tồn tại chính vì lỗi ở đây thuộc về khái niệm chứ không thuộc về cú pháp.

Ví dụ: Một bài nhóm yêu cầu tính giá trị đơn hàng trung bình trên mỗi khách hàng. Câu truy vấn trả về một con số nghe rất hợp lý. Mentor hỏi vậy những khách đã đăng ký mà chưa từng đặt đơn nào thì đi đâu, và cả nhóm lặng đi. Phép nối trong đã loại họ ra, nên con số kia mô tả khách đang hoạt động chứ không phải toàn bộ khách hàng. Chỉ một từ đổi. Phần diễn giải trong báo cáo đổi hoàn toàn, và khuyến nghị dựng trên đó cũng đổi theo, đúng kiểu lỗi mô hình hoá bọc trong lớp vỏ cú pháp đúng mà Connolly và Begg (2015) cảnh báo sinh viên mới học SQL hay mắc phải nhất.

Cùng những kiểu hỏng ấy lặp lại ở các môn cơ sở dữ liệu của trường khác, và bài hướng dẫn INFO20003 Database Systems của Melbourne trình bày kỹ các nghiên cứu đã đo được về lỗi mô hình hoá của người mới.

Những từ khoá SQL hay bị dùng sai ngữ nghĩa

Trả lời trực tiếp: INNER JOIN chỉ giữ dòng khớp ở cả hai bảng, còn LEFT JOIN giữ toàn bộ dòng bảng trái kể cả khi không khớp, đúng lỗi khiến bài tính đơn hàng trung bình bỏ sót khách chưa từng đặt đơn. WHERE lọc dòng trước khi gom nhóm bằng GROUP BY, còn HAVING lọc sau khi các hàm gộp như COUNT, SUM, AVG đã tính xong, nên đặt sai vị trí thường âm thầm đổi con số trả về.

Vì phần lớn điểm mất ở SQL là lỗi suy luận chứ không phải lỗi cú pháp, đúng khác biệt mà Elmasri và Navathe (2016) dành hẳn nhiều chương để giảng, đáng để gọi đúng tên từng cặp khái niệm hay bị lẫn.

INNER JOIN chỉ giữ lại những dòng có bản ghi khớp ở cả hai bảng, còn LEFT JOIN giữ toàn bộ dòng của bảng bên trái kể cả khi không có bản ghi khớp ở bảng bên phải, đúng phép nối khiến bài tính đơn hàng trung bình ở ví dụ trên bỏ sót khách chưa từng đặt đơn. WHERE lọc dòng trước khi gom nhóm bằng GROUP BY, còn HAVING lọc sau khi các hàm gộp như COUNT, SUM, AVG hay MAX đã tính xong, nên đặt sai vị trí hai mệnh đề này thường không báo lỗi mà chỉ âm thầm đổi con số trả về. Một truy vấn con lồng trong mệnh đề FROM và một Common Table Expression viết bằng WITH thường cho cùng kết quả, nhưng CTE dễ đọc lại hơn khi bạn phải giải thích từng bước cho người chấm.

Bài nhóm thì khác gì?

Trả lời trực tiếp: Môn dạng này thường chia phần đánh giá thành bài cá nhân rồi tới bài nhóm, nghĩa là rủi ro dịch chuyển từ năng lực kỹ thuật sang tính nhất quán. Điểm rơi rớt khi bốn người viết bốn phần bằng bốn hệ từ vựng khác nhau, khi tên thực thể trên sơ đồ không khớp tên bảng lúc triển khai, và khi giả định của người này bị câu truy vấn của người kia phủ định.

Hãy luôn kiểm tra cấu trúc và trọng số đánh giá cụ thể của lớp mình trên Moodle, vì cách chia này thay đổi theo từng kỳ, và vì tính nhất quán về tên gọi chính là chiều chất lượng mà Chen (1976) thiết kế ký pháp thực thể liên kết để bảo vệ.

Bằng chứng: Làm việc nhóm hiệu quả là một chuẩn đầu ra được gọi tên của môn chứ không phải một đặc điểm tình cờ của cách chia bài. Tính mạch lạc cũng là một chiều chất lượng độc lập của mô hình dữ liệu, đứng ngang hàng với tính đúng và tính đầy đủ (Moody & Shanks, 2003). Một mô hình mà mỗi người đọc hiểu một kiểu là mô hình đã thất bại ở đúng chức năng mà ký pháp sinh ra để làm, và bài nhóm là nơi dễ lộ thất bại đó nhất.

Ví dụ: Một nhóm bốn người, trong đó ba bạn người Việt, nộp báo cáo mà sơ đồ ghi Customer, lược đồ ghi Client, còn câu SQL đặt bí danh cho cả hai là c. Không có gì sai về kỹ thuật. Nhận xét của người chấm là thiết kế khó theo dõi, mà khó theo dõi lại đúng là một tiêu chí. Cách mentor xử lý là dành 15 phút rà lại tên gọi trước khi nộp, và giờ đây đó là việc đầu tiên mentor MAAS yêu cầu một nhóm làm cơ sở dữ liệu phải làm.

Các khái niệm mô hình hoá bạn cần gọi tên chính xác

Trả lời trực tiếp: PK, tức khoá chính, xác định duy nhất mỗi dòng trong một bảng, còn FK, tức khoá ngoại, tham chiếu tới khoá chính của bảng khác để biểu diễn quan hệ. Quan hệ một-một là mỗi dòng bảng này khớp đúng một dòng bảng kia, một-nhiều là một dòng bảng cha khớp nhiều dòng bảng con, còn nhiều-nhiều cần thêm bảng trung gian, đúng dạng bảng liên hệ mà ví dụ nhà cung cấp còn thiếu.

Một sơ đồ dùng đúng ký hiệu nhưng gọi sai tên khái niệm trong phần lập luận vẫn mất điểm, vì người chấm chấm cách bạn nói về mô hình chứ không chỉ chấm hình vẽ, đúng chiều mức dễ hiểu mà Moody và Shanks (2003) xếp ngang hàng với tính đúng.

PK, tức khoá chính, xác định duy nhất mỗi dòng trong một bảng, còn FK, tức khoá ngoại, tham chiếu tới khoá chính của một bảng khác để biểu diễn mối quan hệ. Một quan hệ một-một nghĩa là mỗi dòng ở bảng này khớp với đúng một dòng ở bảng kia, một quan hệ một-nhiều là một dòng ở bảng cha khớp với nhiều dòng ở bảng con, còn một quan hệ nhiều-nhiều cần thêm một bảng trung gian mới biểu diễn được, đúng dạng bảng liên hệ mà ví dụ nhà cung cấp ở trên còn thiếu. Một thực thể yếu không tự có PK mà phải mượn một phần khoá từ thực thể mà nó phụ thuộc, còn một khoá phức hợp gồm nhiều cột gộp lại vẫn chỉ là một PK, chỉ là PK nhiều cột, thường xuất kèm dữ liệu mẫu dưới định dạng CSV khi đề bài yêu cầu nộp cả bảng dữ liệu thử.

Nên làm việc theo trình tự nào trong suốt kỳ?

Trả lời trực tiếp: Mô hình hoá trước khi dựng, và viết trước khi hoàn thiện. Trình tự chạy được là: đọc đề hai lần và đánh dấu mọi danh từ có thể là thực thể cùng mọi động từ có thể là mối quan hệ, liệt kê các chỗ mơ hồ, xử lý chúng bằng chữ viết, vẽ mô hình thực thể liên kết, ánh xạ sang các quan hệ, chuẩn hoá và ghi lại mỗi bước đã sửa được điều gì, triển khai, rồi mới viết truy vấn kèm câu hỏi bằng lời thường đặt ngay bên trên. Sinh viên triển khai trước gần như luôn phát hiện lỗi mô hình hoá vào lúc đã quá muộn để sửa cho rẻ, đúng cấu trúc ổn định mà Codd (1970) muốn tầng logic giữ được bất kể tầng vật lý thay đổi ra sao.

Bằng chứng: Trình tự khái niệm rồi logic rồi vật lý là phương pháp thiết kế chuẩn trong các giáo trình mà môn học dựa vào, và nó tồn tại vì chi phí làm lại tăng vọt qua mỗi giai đoạn (Connolly & Begg, 2015). Sửa một mối quan hệ trên giấy mất vài phút. Cũng phép sửa đó sau khi đã triển khai thì đụng tới lược đồ, tới dữ liệu và tới mọi câu truy vấn dựng trên đó.

Ví dụ: Một bạn nam dựng lại lược đồ tới lần thứ ba trong tuần cuối được mentor đề nghị ngừng động vào cơ sở dữ liệu và dành một tiếng quay lại với sơ đồ. Bạn phát hiện một mối quan hệ đã bị mô hình hoá ngược ngay từ đầu, và điều đó giải thích cả ba lần dựng lại, đúng chi phí tăng vọt theo từng giai đoạn mà Connolly và Begg (2015) mô tả cho trình tự khái niệm rồi logic rồi vật lý. Cái tiếng đồng hồ tưởng như trì hoãn lại chính là tiếng đồng hồ chấm dứt vòng lặp.

Công cụ và ngôn ngữ con thường gặp

Trả lời trực tiếp: Môn thường dùng một hệ quản trị cơ sở dữ liệu quan hệ như MySQL, PostgreSQL hoặc SQL Server, cùng một công cụ vẽ sơ đồ như MySQL Workbench hay Lucidchart. DDL, tức Data Definition Language, tạo và sửa cấu trúc bảng qua CREATE, ALTER, DROP, còn DML, tức Data Manipulation Language, thao tác dữ liệu qua SELECT, INSERT, UPDATE, DELETE. OLTP phục vụ vận hành hằng ngày, OLAP phục vụ báo cáo.

Các môn cơ sở dữ liệu bậc đại học ở Úc thường dùng một hệ quản trị cơ sở dữ liệu quan hệ, viết tắt RDBMS, như MySQL, PostgreSQL hoặc Microsoft SQL Server để sinh viên thực hành, và một công cụ vẽ sơ đồ như MySQL Workbench hay Lucidchart cho phần mô hình hoá.

Bản thân SQL chia thành nhiều ngôn ngữ con. DDL, tức Data Definition Language, dùng để tạo và sửa cấu trúc bảng qua các lệnh CREATE, ALTER, DROP và RENAME. DML, tức Data Manipulation Language, dùng để thao tác dữ liệu qua các lệnh SELECT, INSERT, UPDATE và DELETE, đúng cách phân loại mà Connolly và Begg (2015) dùng xuyên suốt giáo trình. Phân biệt đúng hai nhóm lệnh này, chứ không gộp chung là SQL, cũng là một chỗ hay bị hỏi trong phần lý thuyết. Vài mệnh đề khác cũng hay bị nhầm nghĩa: LIMIT chỉ cắt bớt số dòng hiển thị chứ không thay đổi phép tính phía trên nó, LIKE khớp mẫu ký tự chứ không khớp giá trị chính xác, ORDER BY sắp xếp kết quả nhưng không lọc bớt dòng nào, DESC đảo chiều sắp xếp mặc định từ tăng dần sang giảm dần, UNION gộp kết quả của nhiều truy vấn lại làm một trong khi loại trùng lặp, EXISTS chỉ kiểm tra có dòng khớp hay không chứ không trả về giá trị của dòng đó, còn NULL không bằng số 0 và không bằng chuỗi rỗng, nên so sánh bằng dấu bằng thường cho kết quả sai.

Khi đề cập tới dữ liệu lớn, đề bài có thể phân biệt OLTP, tức hệ xử lý giao dịch trực tuyến phục vụ vận hành hằng ngày, với OLAP, tức hệ phân tích trực tuyến phục vụ báo cáo và ra quyết định, và quy trình ETL, tức trích xuất rồi chuyển đổi rồi nạp dữ liệu, nối hai thế giới đó lại với nhau, thường trao đổi qua các định dạng như JSON hoặc XML khi dữ liệu đến từ một API bên ngoài.

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

Không biết lập trình thì có học tốt COMM2822 được không?
Được. SQL là ngôn ngữ truy vấn khai báo chứ không phải ngôn ngữ lập trình theo nghĩa thông thường, và môn học vốn thiết kế cho sinh viên khối kinh doanh. Người học chật vật thường chật vật ở chỗ xử lý mơ hồ khi mô hình hoá, không phải ở cú pháp, đúng khoảng mơ hồ mà ký pháp của Chen (1976) được dựng ra để buộc người thiết kế phải làm rõ.

Thiết kế của mình khác bạn cùng lớp thì có phải là sai không?
Không hẳn. Hai mô hình đều bảo vệ được vẫn có thể khác nhau ở những chỗ đề bài mơ hồ. Cái phân định là bài nào nêu rõ giả định tạo ra khác biệt đó và theo nó tới cùng một cách nhất quán, đúng tiêu chí đa chiều mà Moody và Shanks (2003) đặt ra thay vì một đáp án duy nhất.

Sơ đồ chiếm bao nhiêu điểm so với phần SQL?
Tỷ lệ này thay đổi theo kỳ nên hãy đọc đề bài của chính lớp mình. Điều ổn định là phần lập luận bằng chữ quanh cả hai đáng giá hơn sinh viên tưởng, và đó cũng là phần hay bị để dành tới tiếng cuối cùng.

Có nên chuẩn hoá vượt quá dạng chuẩn thứ ba không?
Chỉ nên nếu bạn giải thích được vì sao, và chỉ khi tình huống đề bài đòi hỏi. Đi xa hơn mà không có lý do sẽ dẫn tới câu hỏi bạn đang giải quyết vấn đề gì, mà trả lời rằng cho kỹ thì không phải câu trả lời kiếm được điểm, vì mỗi dạng chuẩn theo Kent (1983) tồn tại để xử lý một loại rắc rối cụ thể, không phải để trưng ra cho nhiều.

Môn có dạy cả dữ liệu lớn chứ không riêng cơ sở dữ liệu quan hệ phải không?
Đúng vậy. Nguyên lý và đặc trưng của dữ liệu lớn được nêu ngay trong phần mô tả môn, còn các hệ quả đạo đức, quyền riêng tư và an ninh của dữ liệu lớn là một trong năm chuẩn đầu ra. Một bài hướng dẫn coi môn này chỉ gồm cơ sở dữ liệu quan hệ là đang mô tả thiếu.

Bài dùng kiểu trích dẫn nào và dài bao nhiêu chữ?
Hãy xác nhận cả hai trong đề bài của lớp mình, vì báo cáo kỹ thuật thay đổi theo kỳ. Điều ổn định là mọi nguyên lý thiết kế bạn dựa vào đều nên được ghi nguồn, và một báo cáo chủ yếu gồm sơ đồ với mã lệnh vẫn cần nguồn cho các khái niệm đứng sau chúng.

MAAS có hỗ trợ COMM2822 không?
Có. Dịch vụ hỗ trợ học thuật của MAAS đồng hành cùng bạn theo mô hình Outline → Draft → Final, gồm giải mã tình huống đề bài, lập bản đồ giả định, rà soát thiết kế và kiểm tra logic truy vấn cùng mentor có nền tảng dữ liệu. Chúng tôi hướng dẫn bài của bạn, không viết hộ bạn.

Sẵn sàng bước vào COMM2822 với một thiết kế bảo vệ được?

Trả lời trực tiếp: Nếu cơ sở dữ liệu chạy được mà bạn chưa giải thích nổi vì sao nó có hình dạng như vậy, Hỗ trợ học thuật của MAAS đi theo trình tự Outline → Draft → Final, kèm mục tiêu điểm ba mức và 90 ngày hỗ trợ sau khi nộp. Gửi đề bài COMM2822, MAAS ghép bạn với mentor mảng quản trị dữ liệu, 23% trong hơn 100 chuyên gia có bằng Tiến sĩ, trong vòng 48 giờ.

Nếu cơ sở dữ liệu của bạn chạy được mà bạn vẫn chưa giải thích nổi vì sao nó lại có hình dạng như vậy, thì đúng khoảng trống đó là chỗ một mentor phát huy tác dụng. Hỗ trợ học thuật của MAAS làm việc bên cạnh bạn theo trình tự Outline → Draft → Final để các quyết định thiết kế vẫn là của bạn còn lập luận phía sau thì hiện ra rõ ràng trước mắt người chấm. Mỗi lượt đồng hành đều đi kèm mục tiêu điểm ba mức (Pass / Merit / Distinction) và 90 ngày hỗ trợ sau khi nộp bài.

Bạn gửi đề bài COMM2822 và bên mình ghép bạn với mentor mảng quản trị dữ liệu, 23% trong hơn 100 chuyên gia của MAAS có bằng Tiến sĩ, trong vòng 48 giờ.

Đặt lịch tư vấn miễn phí 20 phút về COMM2822 cùng MAAS →

Bài liên quan

• COMM1190: vì sao biểu đồ đúng vẫn chỉ được điểm giữa?: môn anh em ở UNSW về chuyện biến kết quả phân tích thành một quyết định
• COMM2501: kể chuyện bằng dữ liệu tới đâu thì thành bóp méo dữ liệu?: về đạo đức của công việc thuyết phục bằng dữ liệu
• Cách tiếp cận bài ISYS3453 Data Analytics ở RMIT: một điểm đối chiếu từ môn phân tích dữ liệu khác ở Úc
• Hướng dẫn bài ACC203 Accounting Information Systems: tư duy hệ thống áp vào dữ liệu kế toán
• Dịch vụ Đồng hành học thuật MAAS: kèm 1:1 cùng mentor trình độ Tiến sĩ đúng chuyên ngành
• Đồng hành bài tập theo mã môn: bài trụ về cách xử lý bài tập của bất kỳ môn nào cùng mentor MAAS

References

• Codd, E. F. (1974). Recent investigations into relational data base systems. Information Processing 74: Proceedings of IFIP Congress, 1017–1021.
• Chen, P. P.-S. (1976). The entity-relationship model: Toward a unified view of data. ACM Transactions on Database Systems, 1(1), 9–36. https://doi.org/10.1145/320434.320440
• Codd, E. F. (1970). A relational model of data for large shared data banks. Communications of the ACM, 13(6), 377–387. https://doi.org/10.1145/362384.362685
• Connolly, T., & Begg, C. (2015). Database systems: A practical approach to design, implementation, and management (6th ed.). Pearson.
• Elmasri, R., & Navathe, S. B. (2016). Fundamentals of database systems (7th ed.). Pearson.
• Kent, W. (1983). A simple guide to five normal forms in relational database theory. Communications of the ACM, 26(2), 120–125. https://doi.org/10.1145/358024.358054
• Moody, D. L., & Shanks, G. G. (2003). Improving the quality of data models: Empirical validation of a quality management framework. Information Systems, 28(6), 619–650. https://doi.org/10.1016/S0306-4379(02)00043-1

Tools & resources

• UNSW Sydney. (n.d.). UNSW Handbook: COMM2822 Introduction to Databases for Business Analytics. Truy cập ngày 17 tháng 8, 2026, từ https://www.handbook.unsw.edu.au/undergraduate/courses/2026/COMM2822
• UNSW Sydney. (n.d.). UNSW Library. Truy cập ngày 17 tháng 8, 2026, từ https://www.library.unsw.edu.au

Bài viết thuộc chuyên mục MAAS Journal dành cho du học sinh Việt Nam. hỗ trợ học thuật của MAAS là đối tác cố vấn, đồng hành cùng sinh viên theo mô hình Outline → Draft → Final với phản hồi phát triển từ mentor trình độ Tiến sĩ. Chúng tôi không viết hộ hay nộp bài thay sinh viên.