Trả lời ngắn: BA không bắt buộc phải biết SQL, nhưng nên biết ở mức SELECT, JOIN, GROUP BY, mức đó đủ để tự trả lời phần lớn câu hỏi dạng bao nhiêu, mấy cái, theo từng tháng, và đủ để kiểm tra requirement với dữ liệu thật, không cần học tới mức developer.
Thử hình dung cuộc họp với phòng kinh doanh, trưởng phòng hỏi tháng trước có bao nhiêu đơn bị khách trả lại, chủ yếu là sản phẩm nào, bạn hứa sẽ gửi số, về chỗ nhắn dev nhờ lấy, dev đang chạy deadline nên ba ngày sau mới có file, mà tới lúc đó câu hỏi đã đổi, cuộc họp tiếp theo cũng đã diễn ra rồi. Tình huống kiểu này là lý do nhiều BA bắt đầu học SQL, và câu hỏi là học tới đâu thì vừa, để khỏi mất cả năm cày khóa database.
SQL với BA để làm gì#
Với BA, SQL là cái ống nhòm nhìn vào dữ liệu, vì phần lớn câu hỏi stakeholder đặt ra có dạng bao nhiêu, mấy cái, từ khi nào, theo từng nhóm nào, mấy câu này chỉ cần vài dòng query. Nó giúp hai việc. Việc thứ nhất là tự trả lời câu hỏi nghiệp vụ, đỡ phải xếp hàng chờ dev. Việc thứ hai, ít người nói tới hơn, là kiểm tra requirement, trước khi viết “báo cáo hiển thị lý do trả hàng” thì mở dữ liệu ra xem hệ thống có lưu lý do trả hàng không, lưu dạng chọn từ danh sách hay gõ tự do, vì câu trả lời đổi hẳn cách bạn viết requirement.
Bài Làm BA có cần biết code không bàn rộng hơn về kiến thức kỹ thuật cho BA, bài này chỉ tập trung vào SQL.
ba câu lệnh là đủ sống#
SELECT là đọc dữ liệu ra, lấy những cột nào, từ bảng nào, đi kèm là WHERE để lọc, ví dụ đơn tạo trong tháng 9 có trạng thái đã trả, đây là câu bạn dùng nhiều nhất.
SELECT order_no, customer_id, status
FROM orders
WHERE order_date >= '2026-09-01' AND status = 'RETURNED';JOIN là ghép hai bảng. Bảng đơn hàng thường chỉ lưu mã khách, còn tên khách nằm ở bảng khách hàng, muốn biết đơn của ai thì JOIN hai bảng qua mã khách, hiểu JOIN là hiểu vì sao dữ liệu không nằm một cục, và đây cũng là chỗ ERD giúp bạn rất nhiều, bài ERD cho BA có hướng dẫn đọc sơ đồ quan hệ bảng.
GROUP BY là gom nhóm rồi đếm hoặc cộng, câu hỏi nào có chữ “mỗi” hoặc “theo từng” thì gần như chắc chắn cần GROUP BY kèm COUNT hoặc SUM.
SELECT p.product_name, COUNT(*) AS so_don_tra
FROM orders o
JOIN products p ON p.product_id = o.product_id
WHERE o.status = 'RETURNED'
GROUP BY p.product_name
ORDER BY so_don_tra DESC;Hai câu trên trả lời đúng câu hỏi của trưởng phòng ở đầu bài, còn tên bảng và cột chỉ là ví dụ, hệ thống thật sẽ khác.
chỗ hay sai là đếm sai vì JOIN sai#
Lỗi phổ biến của người mới không nằm ở cú pháp mà ở chỗ JOIN nhân bản dòng, một đơn hàng có ba dòng sản phẩm, JOIN sang bảng chi tiết rồi COUNT(*) thì một đơn hóa thành ba, con số trông rất hợp lý, chỉ có điều là sai, mà đem số sai vào cuộc họp thì còn tệ hơn không có số. Cách tránh là trước khi đếm tự hỏi một dòng kết quả đang đại diện cho cái gì, một đơn hay một dòng sản phẩm, cần đếm đơn thì dùng COUNT(DISTINCT order_no), và luôn đối chiếu một hai con số với màn hình báo cáo có sẵn trong hệ thống trước khi gửi đi.
bắt đầu học từ đâu#
Đừng mở đầu bằng một khóa lý thuyết dài về cơ sở dữ liệu, lấy một bộ dữ liệu mẫu có vài bảng liên quan tới nhau kiểu khách hàng, đơn hàng, sản phẩm, nhiều hệ quản trị cơ sở dữ liệu có sẵn database mẫu như vậy, hoặc bạn tự tạo vài bảng nhỏ trong SQLite. Rồi tự đóng vai stakeholder đặt mười câu hỏi, mỗi tháng có bao nhiêu đơn, khách nào mua nhiều nhất, sản phẩm nào chưa bán được lần nào, mỗi câu viết một query, chạy, rồi tự kiểm tra bằng cách đếm tay trên vài dòng, câu nào không viết được là đúng chỗ bạn cần học tiếp. Cách này chậm hơn xem video, nhưng thứ bạn nhớ được là cách biến câu hỏi nghiệp vụ thành query, đúng cái BA cần.
đừng đâm đầu làm DBA#
Học SQL đủ dùng khác với chạy theo database, BA không cần viết stored procedure, tối ưu index hay lo phân quyền với backup, đó là việc của dev và DBA, và nhiều nơi cũng chỉ cho BA quyền đọc trên môi trường test hoặc bản sao dữ liệu, như vậy là hợp lý. Một mẹo nhỏ là khi viết acceptance criteria cho báo cáo, chạy thử query để chắc field cần dùng có tồn tại và có dữ liệu, phát hiện thiếu field ở bước viết tài liệu rẻ hơn nhiều so với lúc dev đã code xong.
Cứ học lần lượt SELECT, JOIN, GROUP BY, tập trên một bộ dữ liệu mẫu, rồi đem ra trả lời câu hỏi thật trong công việc, đủ dùng là đủ, phần sức còn lại để dành cho phân tích. Có câu hỏi dữ liệu nào bạn đang phải chờ người khác lấy số mà nghĩ lại thì tự viết query được không? Kể mình nghe qua Facebook hoặc LinkedIn.
