Database Concepts không rớt vì SQL khó. Nó rớt vì sinh viên xem assignment như bài lý thuyết, trong khi đề thật chấm bạn như một người thiết kế database: vẽ đúng ER, map đúng sang relational model, chuẩn hóa đến 3NF, rồi chứng minh database chạy được bằng query thật. Bài này đi theo đúng cấu trúc đề các kỳ trước, kèm thang điểm từng phần để bạn biết công sức nên đổ vào đâu.

Số liệu trong bài lấy từ đề và course guide các kỳ trước (một số bản gốc thuộc kỳ 2021, 2022). Trọng số và dataset có thể đổi theo kỳ, mở Canvas đúng kỳ của bạn để đối chiếu trước khi làm.

Cấu trúc đánh giá: điểm nằm ở hai bài design

Theo đề các kỳ trước, hai assessment nặng nhất của môn này là:

  • Assessment 1: Database Design, 20%. Part A vẽ ER Modelling bằng ký hiệu UML trên Lucidchart (12 điểm), Part B chuyển sang Relational Database Model (8 điểm). Chỉ riêng phân bổ này đã nói lên một điều: phần vẽ ER chiếm 60% số điểm của A1, đừng dồn hết thời gian cho phần chuyển đổi.
  • Database Design Project, 35%, dạng take-home. Đây là bài lớn nhất môn, chia điểm theo task: hiểu dữ liệu (0 điểm nhưng bắt buộc), thiết kế database (10 điểm), tạo database bằng SQL (10 điểm), truy vấn dữ liệu (15 điểm). Task truy vấn chiếm nhiều điểm nhất, và cũng là task sinh viên hay bỏ bê nhất vì nằm cuối đề.

Case study thật: dữ liệu vaccine COVID toàn cầu

Kỳ 2021, 2022 đề dùng bộ dữ liệu A Global Database of COVID-19 Vaccinations lấy từ Our World in Data: 8 file CSV gồm dữ liệu theo quốc gia, theo bang của Mỹ, theo nhóm tuổi và theo nhà sản xuất vaccine. Nhiệm vụ của bạn là biến đống CSV đó thành một database SQLite chuẩn hóa. Dataset có thể đổi theo kỳ, nhưng cái khung không đổi: dữ liệu thô nhiều file, có trùng lặp, có cột thừa, và bạn phải thiết kế schema sạch từ nó.

Bộ file nộp bài của các kỳ trước gồm 5 món: Design.pdf (ER diagram kèm assumptions và schema), database.sql (toàn bộ lệnh CREATE TABLE), file .db đã đổ dữ liệu (ví dụ Vaccinations.db), queries.sql, và results.pdf chụp kết quả kèm biểu đồ. Thiếu món nào là mất điểm món đó, không ai nhắc bạn.

Vẽ ER diagram: đúng và sai

Làm đúng là đọc kỹ mô tả dữ liệu, gạch chân danh từ lặp lại (country, vaccine, date, manufacturer), quyết định cái nào là entity, cái nào chỉ là attribute, rồi đặt cardinality cho từng quan hệ và ghi rõ assumption cho mọi quyết định không hiển nhiên. Ví dụ một assumption tốt: 'Mỗi quốc gia báo cáo nhiều đợt số liệu theo ngày, mỗi đợt thuộc đúng một quốc gia, nên Country và VaccinationRecord là quan hệ 1-N.'

Làm sai là vẽ mỗi CSV thành một entity. Đề cho 8 file không có nghĩa là database có 8 bảng. File là cách dữ liệu được phát hành, không phải cách dữ liệu nên được tổ chức. Người chấm nhìn vào chỗ này đầu tiên để biết bạn có hiểu modeling hay chỉ đang sao chép cấu trúc file.

Một lỗi mất điểm lãng xẹt nữa: dùng ký hiệu Chen trong khi đề yêu cầu UML trên Lucidchart. Sai notation là mất điểm ngay cả khi thiết kế đúng.

Từ ER sang relational: quy trình 7 bước là thứ được chấm

Đề các kỳ trước ghi rõ tiêu chí: áp dụng quy trình ánh xạ 7 bước từ ER sang relational model và chuẩn hóa đến 3NF. Nghĩa là bạn không được nhảy thẳng từ diagram sang CREATE TABLE. Trình bày từng bước: map strong entity, map weak entity, map quan hệ 1-1, 1-N, N-N (sinh bảng trung gian với khóa ghép), map multivalued attribute.

Viết đúng khi nói về chuẩn hóa là chứng minh: chỉ ra functional dependency, chỉ ra vi phạm (partial dependency, transitive dependency), rồi tách bảng và nói rõ tách để loại vi phạm nào. Viết sai là tuyên bố 'các bảng đều đạt 3NF' mà không có một dòng chứng minh. Câu mẫu bạn có thể dùng: 'Bảng VaccinationByAge vi phạm 2NF vì age_group_share chỉ phụ thuộc vào age_group chứ không phụ thuộc cả khóa ghép (country, date, age_group), nên tách thành bảng AgeGroup riêng.'

Task truy vấn 15 điểm: nơi bài HD bỏ xa bài trung bình

Đề kỳ trước có 5 câu truy vấn, và độ khó tăng dần đúng kiểu phân loại điểm: so sánh số liều đã tiêm giữa hai mốc ngày, tìm các quốc gia vượt mức tiêm trung bình, top 10 quốc gia dùng nhiều loại vaccine nhất, tổng liều theo nguồn dữ liệu, và so sánh tốc độ tiêm năm 2022 giữa bốn quốc gia. Ba câu cuối đều cần aggregate lồng subquery hoặc join nhiều bảng.

Nên làm: viết query trên chính schema mình thiết kế ngay từ khi thiết kế xong. Nếu một câu hỏi buộc bạn join 5 bảng lòng vòng mới ra đáp án, đó là tín hiệu schema đang thiết kế dở, quay lại sửa design trước khi quá muộn. Đây là vòng lặp design, query, sửa design mà bài điểm cao nào cũng đi qua.

Không nên làm: chỉ dán SQL khô vào queries.sql. File results.pdf các kỳ trước yêu cầu chụp kết quả kèm visualisation. Một biểu đồ cột đơn giản từ kết quả query là điểm trình bày gần như miễn phí.

Checklist trước khi nộp

  1. ER diagram vẽ bằng đúng notation đề yêu cầu (UML, Lucidchart), mọi cardinality có ghi chú.
  2. Assumptions viết thành mục riêng trong Design.pdf, mỗi quyết định mơ hồ một dòng.
  3. Quy trình 7 bước trình bày tường minh, không nhảy cóc.
  4. Mỗi bảng có một đoạn chứng minh 3NF, chỉ ra dependency cụ thể.
  5. database.sql chạy sạch từ đầu đến cuối trên SQLite Studio, đúng thứ tự tạo bảng theo khóa ngoại.
  6. Đủ 5 file nộp, đặt tên đúng format đề yêu cầu.

Nếu bạn muốn luyện cách trình bày lập luận thiết kế cho chặt (vì Design.pdf thực chất là một bài viết học thuật mini), bài phát triển luận điểm chặt chẽ trong thân bài của tụi mình áp dụng được nguyên xi cho phần assumptions và justification.

Còn nếu bạn đã có bản design và muốn một người soi lại schema trước khi nộp (khóa ghép đặt đúng chưa, 3NF chứng minh đủ chưa, query có tối ưu không), tụi mình nhận review bài theo đúng thang điểm từng task. Chi tiết ở bảng báo giá của 7 Writing Service nhé.

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

Project 35% có làm nhóm không?

Các kỳ trước đây là bài take-home cá nhân. Kiểm tra đề kỳ bạn học vì cấu hình nhóm hay cá nhân là thứ RMIT đổi thường xuyên nhất.

Dùng MySQL hay PostgreSQL thay SQLite được không?

Không, khi đề đã chỉ định SQLite. Người chấm mở file .db của bạn bằng SQLite Studio; nộp dump của hệ khác là rủi ro không chạy được, mà không chạy được thì task tạo database 10 điểm về 0.

ER diagram sai thì các task sau có bị trừ dây chuyền không?

Có phần. Task tạo database và truy vấn được chấm trên schema bạn nộp, nên một design sai vẫn có điểm ở task sau nếu SQL nhất quán với design đó. Nhưng design sai nặng (thiếu entity, sai cardinality) thường kéo theo query không trả lời nổi câu hỏi của đề, lúc đó mới mất điểm kép.

Cần hỗ trợ 1-1 cho môn này? Xem bảng giá và quy trình nhận hỗ trợ của 7 Writing Service.