Mở đầu — vì sao bài này quan trọng
Có một khoảng cách rất lớn giữa việc bạn vẽ được một ERD trên giấy và việc bạn tự tin ngồi trước một schema thật của một hệ thống đang chạy hàng triệu giao dịch mỗi ngày. Suốt gần 55 bài học vừa qua, chúng ta đã làm việc với rất nhiều ví dụ — nhưng phần lớn là ví dụ do tôi thiết kế sẵn để minh họa một khái niệm cụ thể: một entity Customer gọn gàng, một quan hệ many-to-many sạch sẽ, một bảng có đúng năm cột để bạn dễ nhìn. Đó là "toy example" — ví dụ đồ chơi. Chúng hữu ích khi học, nhưng thực tế thì lộn xộn hơn nhiều.
Trong thế giới thật, bạn sẽ gặp những schema có 40 bảng liên kết chằng chịt, những cột có tên viết tắt khó hiểu, những quyết định thiết kế trông "sai" nhưng thực ra có lý do lịch sử, và những bảng audit phình to gấp mười lần bảng gốc. Nếu bạn chỉ luyện tập trên ví dụ đồ chơi, ngày đầu tiên đi làm với một database thật bạn sẽ choáng.
Bài này giải quyết đúng vấn đề đó. Chúng ta sẽ nói về open datasets — những bộ dữ liệu mở, miễn phí, có cấu trúc thật, được cộng đồng và các tổ chức lớn công bố để bất kỳ ai cũng có thể tải về học tập, phân tích và luyện tập. Đây là "phòng gym" tốt nhất cho một Data BA: bạn được sờ vào schema thật, đọc mô hình thật, viết SQL thật, và quan trọng nhất là học cách người khác đã mô hình hóa vấn đề trước bạn. Học từ những schema đã được kiểm chứng qua thời gian nhanh hơn rất nhiều so với tự mò mẫm từ con số không.
Khái niệm cốt lõi
Open dataset là gì và tại sao nó khác toy example
Open dataset là bộ dữ liệu được công bố công khai kèm giấy phép cho phép sử dụng tự do (thường là Public Domain, CC0, hoặc các giấy phép mở khác). Điểm mấu chốt với người làm data modeling không nằm ở bản thân dữ liệu, mà ở cấu trúc đi kèm: schema (định nghĩa bảng và cột), quan hệ giữa các bảng, ràng buộc, và đôi khi cả tài liệu giải thích mô hình.
Khác biệt cốt lõi so với toy example:
- Cấu trúc thật (real-world structure): phản ánh sự phức tạp thật của nghiệp vụ — có ngoại lệ, có trường nullable vì lý do vận hành, có bảng trung gian phát sinh từ yêu cầu thực tế.
- Miễn phí và hợp pháp: bạn không cần lo về bản quyền hay NDA khi thực hành, chia sẻ hay đưa vào portfolio.
- Mô hình chuẩn ngành (industry-standard models): nhiều dataset được thiết kế bởi chuyên gia và đã trở thành "chuẩn tham chiếu" mà cả ngành công nhận.
- Luyện được cả SQL lẫn modeling: bạn vừa viết truy vấn trên dữ liệu thật, vừa reverse-engineer (dựng ngược) sơ đồ ERD từ schema có sẵn.
Ba loại dataset bạn nên phân biệt
Không phải dataset nào cũng phục vụ mục đích giống nhau. Với vai trò Data BA, hãy phân loại theo mục đích sử dụng:
1. Reference schema (schema tham chiếu): những cơ sở dữ liệu mẫu được thiết kế có chủ đích để dạy mô hình hóa. Ví dụ kinh điển là Sakila (mô hình cửa hàng cho thuê DVD của MySQL), Chinook (mô hình cửa hàng nhạc số, đa nền tảng), Northwind (mô hình bán buôn thực phẩm của Microsoft), hay Pagila (bản Sakila cho PostgreSQL). Đây là "sách giáo khoa sống" về ERD — nhỏ vừa đủ để đọc hết, nhưng đủ phức tạp để có quan hệ many-to-many, self-reference, và phân cấp.
2. Real operational data (dữ liệu vận hành thật): dữ liệu do tổ chức thật công bố, phản ánh nghiệp vụ thật. Ví dụ như dữ liệu chuyến taxi của thành phố New York (NYC TLC Trip Records), dữ liệu chuyến bay, hay dữ liệu mở của chính phủ Việt Nam trên data.gov.vn và các cổng dữ liệu mở của TP.HCM. Loại này giúp bạn thấy dữ liệu thật "bẩn" và lớn như thế nào.
3. Analytical / dimensional datasets (dữ liệu phân tích): những bộ dữ liệu phù hợp để luyện thiết kế data warehouse, star schema — như bộ dữ liệu bán lẻ Olist của một sàn thương mại điện tử Brazil (rất giống bối cảnh Shopee/Lazada Đông Nam Á), hay các bộ dữ liệu bán lẻ trên Kaggle.
Nguồn tìm dataset đáng tin cậy
Bạn không cần lang thang khắp Internet. Có vài nguồn "mỏ vàng" đáng nhớ:
- Kaggle Datasets: kho lớn nhất, có kèm mô tả cột và thường có notebook mẫu.
- Repository chính thức của DBMS: MySQL (Sakila, world, employees), PostgreSQL (Pagila, dvdrental), SQL Server (AdventureWorks, WideWorldImporters).
- Google Dataset Search và UCI Machine Learning Repository: để tìm theo chủ đề.
- Cổng dữ liệu mở chính phủ: data.gov.vn, opendata.hcmc.gov.vn, và tương đương ở Singapore (data.gov.sg) — rất giá trị khi bạn muốn bối cảnh địa phương.
- Awesome Public Datasets trên GitHub: danh sách tổng hợp được cộng đồng duy trì.
Tình huống thực tế
Tình huống 1 — Học viên chuyển ngành dùng Sakila để lấp lỗ hổng kiến thức
Chị Vân, 29 tuổi, từng làm kế toán tại một công ty logistics ở Hải Phòng, muốn chuyển sang vai trò Data BA. Chị đã học xong lý thuyết normalization nhưng chưa từng đọc một schema thật nào có trên 5 bảng. Thay vì tiếp tục học lý thuyết, chị tải Sakila về MySQL local.
Sakila mô phỏng một chuỗi cửa hàng cho thuê phim với 16 bảng: film, actor, customer, rental, payment, inventory, store, staff, address, city, country... Trong hai tuần, chị Vân làm ba việc: (1) dùng công cụ dựng ngược ERD từ schema; (2) tự lý giải vì sao có bảng trung gian film_actor — và nhận ra đó chính là quan hệ many-to-many giữa phim và diễn viên mà chị mới học ở Bài 7; (3) truy vấn tìm top 10 phim được thuê nhiều nhất, buộc chị phải JOIN qua rental → inventory → film.
Bài học rút ra: khi gặp chuỗi bảng address → city → country, chị nhận ra đây là mô hình phân cấp địa lý được chuẩn hóa để tránh lặp lại tên quốc gia hàng nghìn lần — đúng nguyên lý 3NF. Một khái niệm trừu tượng trong Bài 14 bỗng trở nên cụ thể chỉ vì chị được sờ vào một schema thật đã áp dụng nó. Sakila dạy chị nhiều hơn bất kỳ slide lý thuyết nào.
Tình huống 2 — Team analytics dùng dataset Olist để luyện star schema cho một sàn TMĐT Việt Nam
Một startup thương mại điện tử tại TP.HCM (gọi là "ChợViệt") có team data mới thành lập, cần thiết kế data warehouse để làm báo cáo doanh thu. Vấn đề: họ không được phép dùng dữ liệu production thật cho việc học và thử nghiệm vì lý do bảo mật khách hàng. Trưởng nhóm quyết định cho cả team luyện trên bộ Olist Brazilian E-commerce (khoảng 100.000 đơn hàng, 9 bảng CSV liên kết qua khóa).
Bối cảnh Olist gần như song trùng với ChợViệt: có orders, order_items, products, customers, sellers, payments, reviews, và bảng địa lý geolocation. Team dành một sprint để: mô hình hóa lại từ dạng OLTP chuẩn hóa sang star schema với một fact_sales ở giữa và các dimension dim_customer, dim_product, dim_seller, dim_date. Con số cụ thể: bảng order_items có hơn 112.000 dòng, đủ lớn để họ cảm nhận sự khác biệt về hiệu năng khi truy vấn trên mô hình chuẩn hóa so với star schema.
Bài học rút ra: khi chuyển sang production thật với dữ liệu ChợViệt, team đã có sẵn "bản thiết kế mẫu" đã được thử nghiệm. Họ chỉ cần thay đổi phần địa lý (Olist dùng mã bang Brazil, ChợViệt dùng tỉnh/thành Việt Nam — liên hệ Bài 25 về địa chỉ Việt Nam) và bổ sung xử lý tiền tệ VND (Bài 27). Dataset mở đã tiết kiệm cho họ khoảng hai tuần thử-và-sai, vì họ được luyện tay nghề trên một bối cảnh Đông Nam Á tương đồng mà không đụng đến dữ liệu nhạy cảm.
Tình huống 3 — Ứng viên dùng dataset mở để xây portfolio đi phỏng vấn
Anh Tuấn ứng tuyển vị trí Data BA tại một ngân hàng số. Nhà tuyển dụng yêu cầu một sản phẩm chứng minh năng lực. Anh không có dữ liệu ngân hàng thật (đương nhiên), nên dùng bộ dữ liệu mở PKDD'99 Financial Dataset (dữ liệu ngân hàng ẩn danh của Séc, gồm các bảng account, client, loan, transaction, card, district) kết hợp với dữ liệu địa lý mở của Việt Nam.
Anh làm một mini-project: dựng ERD từ dataset, viết data dictionary cho từng bảng, rồi phân tích tỷ lệ nợ xấu theo vùng. Bảng transaction có gần một triệu dòng — đủ để anh trình bày về indexing (Bài 23) một cách thuyết phục.
Bài học rút ra: trong buổi phỏng vấn, thay vì nói "em hiểu về mô hình hóa dữ liệu ngân hàng", anh mở ERD ra và giải thích từng quyết định. Nhà tuyển dụng đánh giá cao vì thấy anh đã làm việc với schema tài chính thật, quy mô thật. Dataset mở biến một tuyên bố suông thành bằng chứng cụ thể.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên bạn áp dụng mỗi khi cầm một open dataset mới về để luyện data modeling:
Bước 1 — Xác định mục tiêu học. Trước khi tải, hỏi rõ bạn muốn luyện gì: reverse-engineer ERD? luyện normalization? thiết kế star schema? Mỗi mục tiêu ứng với loại dataset khác nhau. Muốn học quan hệ và chuẩn hóa thì chọn reference schema như Sakila/Chinook; muốn học warehouse thì chọn Olist hoặc dữ liệu bán lẻ.
Bước 2 — Kiểm tra giấy phép và nguồn gốc. Đọc license (CC0, MIT, ODbL...). Xác nhận bạn được phép dùng cho mục đích của mình, đặc biệt nếu định đưa vào portfolio công khai hay dự án thương mại.
Bước 3 — Nạp dữ liệu vào một DBMS local. Đừng chỉ đọc CSV bằng mắt. Hãy import vào MySQL/PostgreSQL/SQLite thật. Với các reference schema, thường có sẵn file .sql để chạy một lệnh là dựng xong toàn bộ bảng và dữ liệu.
Bước 4 — Dựng ngược ERD (reverse-engineer). Dùng công cụ bạn đã học ở Bài 16 (dbdiagram, draw.io) hoặc chức năng reverse-engineering của DBMS để sinh sơ đồ tự động. Sau đó tự tay đọc lại từng khóa ngoại để hiểu quan hệ, đừng tin sơ đồ tự sinh một cách mù quáng.
Bước 5 — Viết data dictionary rút gọn. Với mỗi bảng, ghi lại: mục đích, khóa chính, khóa ngoại, các cột quan trọng và ràng buộc. Đây là cách rèn kỹ năng ở Bài 17, và cũng buộc bạn thật sự hiểu schema.
Bước 6 — Đặt câu hỏi nghiệp vụ và viết SQL trả lời. Ví dụ: "Doanh thu theo tháng?", "Khách hàng nào chi nhiều nhất?". Việc này buộc bạn JOIN qua nhiều bảng và bộc lộ những chỗ mô hình khó hiểu.
Bước 7 — Đề xuất cải tiến mô hình. Bước nâng cao và giá trị nhất: nhìn schema và tự hỏi "Nếu là tôi, tôi sẽ thiết kế khác chỗ nào? Tại sao họ lại làm thế này?". Đây là lúc bạn chuyển từ người học sang người thiết kế.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ tải về mà không nạp vào database. Nhiều người mở CSV bằng Excel, nhìn qua rồi tưởng đã "học". Không có JOIN, không có ràng buộc thật, bạn không luyện được gì về modeling. Mẹo: luôn import vào một DBMS thật, dù chỉ là SQLite nhẹ nhàng.
Lỗi 2 — Bỏ qua data dictionary. Bạn đoán ý nghĩa cột từ tên, và đoán sai. Ví dụ cột amount trong bảng payment là dương hay âm khi hoàn tiền? Không đọc tài liệu là bạn mô hình hóa sai ngay từ giả định. Mẹo: đọc data dictionary trước, đọc dữ liệu sau.
Lỗi 3 — Tin tưởng dataset là "hoàn hảo". Ngay cả reference schema nổi tiếng cũng có quyết định gây tranh cãi, và dữ liệu vận hành thật thì đầy giá trị thiếu, trùng lặp, sai định dạng. Đó không phải lỗi của bạn — đó là bài học. Hãy ghi lại những chỗ "bẩn" như một phần của việc học về data quality (Bài 46).
Lỗi 4 — Chọn dataset quá lớn ngay từ đầu. Người mới thường lao vào bộ dữ liệu vài chục triệu dòng và bị ngợp. Mẹo: bắt đầu với Sakila hay Chinook (dưới 100 bảng nhỏ), làm chủ rồi mới lên dataset lớn.
Lỗi 5 — Không đối chiếu với bối cảnh Việt Nam. Dataset nước ngoài dùng mã bưu chính, tên bang, đơn vị tiền tệ khác. Nếu bạn định áp dụng vào dự án Việt Nam, hãy chủ động ánh xạ sang địa chỉ, tên, tiền tệ Việt Nam (Bài 25, 26, 27). Mẹo hay: chọn dataset Đông Nam Á hoặc Nam Mỹ (như Olist) vì cấu trúc thị trường gần với ta hơn schema Bắc Mỹ.
Mẹo tổng quát: hãy xây một "thư viện tham chiếu" cá nhân — một thư mục lưu 4-5 dataset yêu thích cùng ERD và data dictionary bạn tự dựng. Khi đi làm gặp bài toán mới, bạn lôi ra so sánh: "À, cái này giống mô hình rental trong Sakila". Đó chính là cách các data architect kỳ cựu làm việc: họ có sẵn một kho pattern trong đầu.
Bài tập thực hành
Bài tập 1 — Reverse-engineer Chinook. Tải bộ Chinook (có sẵn bản cho SQLite, MySQL, PostgreSQL), nạp vào một DBMS local. Dùng công cụ ERD dựng ngược sơ đồ. Sau đó tự trả lời: quan hệ giữa Playlist và Track là loại gì? Bảng nào là bảng trung gian? Viết 3 câu SQL: (a) top 5 nghệ sĩ có nhiều bài hát nhất, (b) tổng doanh thu theo quốc gia khách hàng, (c) hóa đơn trung bình mỗi khách.
Bài tập 2 — So sánh hai schema. Tải cả Sakila và Northwind. Với mỗi bộ, xác định: mô hình xử lý địa chỉ như thế nào? Chúng chuẩn hóa địa lý khác nhau ra sao? Viết một đoạn ngắn (nửa trang) so sánh hai cách tiếp cận và nêu bạn thích cách nào hơn cho một dự án Việt Nam, kèm lý do.
Bài tập 3 — Từ OLTP sang star schema. Tải bộ Olist (hoặc một bộ bán lẻ tương tự trên Kaggle). Vẽ ERD của mô hình gốc, sau đó thiết kế một star schema với fact_sales và ít nhất ba dimension. Ghi rõ bạn xử lý dim_date và địa lý như thế nào. Đây là bài tập bản lề nối kiến thức bài này với Bài 31 về data warehouse.
Bài tập 4 (nâng cao) — Bản địa hóa. Chọn một reference schema bất kỳ, và đề xuất các thay đổi cần thiết để nó phục vụ một doanh nghiệp Việt Nam: cột địa chỉ theo tỉnh/thành/phường, cột tiền tệ VND, xử lý tên tiếng Việt có dấu. Viết DDL cho các bảng đã sửa.
Tóm tắt
Open dataset là công cụ luyện tập mạnh mẽ nhất mà một Data BA có thể tiếp cận miễn phí và hợp pháp. Chúng vượt trội hơn toy example vì mang cấu trúc thật, quy mô thật, và những quyết định thiết kế đã được kiểm chứng. Hãy phân biệt ba loại: reference schema (Sakila, Chinook, Northwind — để học quan hệ và chuẩn hóa), dữ liệu vận hành thật (dữ liệu chính phủ, taxi, ngân hàng — để cảm nhận sự lộn xộn của thực tế), và dữ liệu phân tích (Olist — để luyện star schema).
Quy trình bảy bước — từ xác định mục tiêu, kiểm tra giấy phép, nạp vào DBMS, dựng ngược ERD, viết data dictionary, viết SQL, đến đề xuất cải tiến — sẽ biến mỗi dataset thành một buổi luyện tập trọn vẹn. Tránh những lỗi kinh điển: chỉ mở bằng Excel, bỏ qua data dictionary, hay chọn dataset quá lớn.
Điều quan trọng nhất tôi muốn bạn mang theo: đừng học data modeling trong chân không. Mỗi khi bạn tải một schema thật về, đọc nó kỹ, và tự hỏi "tại sao họ làm thế này", bạn đang học từ hàng nghìn giờ kinh nghiệm của những người thiết kế trước bạn. Hãy xây cho mình một thư viện tham chiếu cá nhân — đó là tài sản nghề nghiệp sẽ theo bạn suốt sự nghiệp Data BA.