BA có thật sự cần biết SQL?
BA có thật sự cần biết SQL?
Đọc tựa đề mất hồn chứ hả anh em. “BA có cần biết SQL hay không?”.
Đây là câu hỏi mình nghĩ khá… trớt quớt, vì mình tin rằng hỏi 10 người làm BA, thì hết 11 người trả lời là rất cần rồi (trong đó có 1 ông bức xúc quá nên confirm 2 lần).
Chưa kể, thông tin bây giờ cứ nhan nhản trên mạng. Từ các tin tuyển dụng, đến các bài viết về BA. Hễ có BA, là phải có SQL. Mà hễ nói đến SQL, là dòm đi dòm lại thế nào cũng có chữ BA. Lạ lùng vậy đóa.
Do đó bài này mình muốn note lại một số thứ về chuyện làm SQL của BA. Hi vọng nó giúp anh em hiểu rõ được bản chất của việc BA dùng SQL: dùng để làm gì, và tại sao lại là SQL?
Nội dung [Hide]
- 1. SQL trong thế giới hiện tại
- 2. SQL là gì?
- 3. BA dùng SQL trong những việc cụ thể nào?
- 3.1. Đồng hành cùng Dev trong quá trình coding
- 3.2. Công cụ đắc lực trong giai đoạn Transition
- 3.3. Data Analysis
- 3.4. Đụng phát là có ngay thông tin
- 3.5. Giúp sức làm reporting, và nói cho Dev hiểu bằng ngôn ngữ SQL
- 4. SQL chỉ là điều cần?
- 5. Tạm kết
1. SQL trong thế giới hiện tại
Từ thời xa xửa xa xưa, thời mà các tổ chức còn vận hành rất thô sơ. Từ công ty, trường học, bệnh viện, nhà hàng, khách sạn, karaoke, bia ôm, mát xa…, mọi thứ được vận hành rất chi là thủ công.
Đó là cái thời mà mọi thông tin, tiến độ, kế hoạch đều được ghi trên giấy, lưu trong sổ, hoặc viết lên bảng để mọi người cùng theo dõi. Tuy nhiên càng về sau thì mức độ cạnh tranh ngày một tăng cao.
Các tổ chức cạnh tranh khốc liệt với nhau từng chút một. Từ vận hành nội bộ sao cho hiệu quả, đến việc phục vụ khách hàng sao cho ngon lành nhất.
Lúc này “công nghệ” phọt ra như một bài thuốc giúp nâng cao hiệu quả hoạt động, và dần “khẳng định chỗ đứng” trong bất kỳ tổ chức nào.
Tức, họ mang những thứ xưa giờ làm trên giấy, ghi trong sổ, viết lên bảng; quăng vào trong máy tính, thứ mà chúng ta hay gọi là “số hóa”. Và điều quan trọng là: một khi đã số hóa được những thứ này, tổ chức sẽ sở hữu được thứ tài sản quan trọng bậc nhất của họ, đó là data.
Nguồn ảnh: envisionapp.com
Có data trong tay,
Các tổ chức sẽ tự động hóa được quy trình làm việc của họ. Bằng cách nào?
Khi mọi thứ đã được quy về dữ liệu, con người và máy tính sẽ cùng hiểu chung một ngôn ngữ. Từ đó chúng ta sẽ lập trình được các ứng dụng, làm cho máy tính hiểu và làm theo những quy trình được thiết kế sẵn, theo đúng vận hành của tổ chức.
Có data trong tay,
Họ sẽ hiểu rõ bức tranh kinh doanh, vận hành của họ, thông qua các báo cáo, dashboard thường ngày.
Có data trong tay,
Các tổ chức sẽ kiểm soát được vận hành của họ. Thông tin nhân viên, nhà máy, thiết bị, lớp học, bệnh viện, quán ăn được minh bạch, rõ ràng, theo từng giai đoạn nhất định. Từ đó tối ưu được nguồn lực hay không là nằm ở đây.
Chưa hết, nếu thử nhìn sang góc độ cá nhân với mỗi người.
Tưởng tượng nếu cuối năm có ai đó gửi cho anh em báo cáo chi tiêu của mình suốt cả năm qua thì sao?
Báo cáo chi tiết đến độ, mình mà mua cọng dây thun buộc quần nó cũng ghi. Nó chỉ ra cho anh em biết được đâu là khoản chi nhiều nhất, thu nhiều nhất, vào thời gian nào, nhân dịp gì, chi với ai…
Rồi dựa vào đống data đó, nó còn dự đoán được cho anh em trong 30 ngày tiếp theo, anh em có thể phải chi ngần này tiền. Từ đó, nó đưa ra kiến nghị chỉ nên chi nhiêu đây thôi… Quá hữu ích đúng không anh em!!!
…
Chúng ta ai cũng hiểu rõ giá trị của data. Tuy nhiên, có data trong tay là một chuyện, làm gì với data mới là quan trọng.
Và thực tế là hầu như chúng ta chỉ có một cách duy nhất để nói chuyện và móc data ra, đó chính là thông qua SQL.
(Và giờ là NoSQL, sẽ đề cập ở các bài sau nhé anh em).
2. SQL là gì?
SQL – Structured Query Language – Ngôn ngữ truy vấn dữ liệu có cấu trúc. Chi tiết hơn thì nó dùng để truy vấn data từ những Relational Database.
Relational Database là cơ sở dữ liệu quan hệ.
Quan hệ là sao, tức nó được tổ chức dưới dạng nhiều bảng, mỗi bảng gồm nhiều dòng, mỗi dòng có một cái key riêng để định danh. Và các dòng dữ liệu ở các bảng nó quan hệ dây mơ rễ má với nhau thông qua các key này.
Vậy nên dữ liệu trong databse nó mới có cấu trúc chặt chẽ, và quan hệ mật thiết với nhau. Đó là Relational Database. Và chúng ta sẽ dùng SQL để lấy data từ các database này.
…
Ví dụ mình là CEO (Chief Entertainment Officer) của một công ty phân bón hiệu 3 con ó.
Một buổi sáng đẹp trời, mình chụp đầu ông Manager của bộ phận sản xuất lại hỏi: “Đơn hàng hôm qua của bà Hà sao rồi, nay giao được chưa?”
Ông Manager mới xem xét một hồi rồi trả lời mình: “ngon lành anh eiii, chiều nay là xuất kho!!!”
Tức mình đang cần truy vấn thông tin, mình muốn xem thử đơn hàng hôm qua của bà Hà được xử lý tới đâu rồi, nay giao được chưa.
Mình đang dùng một thứ language là tiếng Việt để truy vấn ông Manager, rồi ổng trả về kết quả cho mình là: “ok đã sẵn sàng giao”.
Chuyển qua lăng kính SQL.
Vì ông sếp bên bộ phận sản xuất chứa rất nhiều thông tin liên quan đến sản xuất nên mình sẽ xem ổng như một hệ thống để quản lý cơ sở dữ liệu, gọi là: Database Management System – DBMS (hệ quản trị cơ sở dữ liệu).
Và thay vì mình nói language tiếng Việt với ổng, thì mình sẽ viết language SQL để hệ thống quản lý database này nó hiểu mình muốn lấy gì.
Tức thay vì nói: “Cho tui xem trạng thái đơn hàng của khách hàng tên Hà gì đó mà được tạo hôm qua, tui muốn kiểm tra xem hôm nay đơn hàng đã sẵn sàng giao được chưa”, thì mình sẽ viết bằng câu SQL như sau:
SELECT
SO.name AS Name,
SO.customerid AS Customer,
SO.statecode AS Status,
SO.transactioncurrencyid AS Currency,
SO.pricelevelid AS Price List,
SO.totalamountbeforediscount AS Total Amount Before Discount,
(Muốn xem cái gì, select ra xem)
FROM salesorder SO
(Cái muốn xem đó từ đâu ra, từ bảng nào)
LEFT INNER JOIN contact CO ON SO.contactid = CO.customerid AND CO.fullname LIKE ‘%Hà%’
(Link tới bảng Contact chứa dữ liệu của chị Hà, Hà gì đó không nhớ, nói chung có chứa chữ Hà là được)
WHERE SO.createdon = DATEADD(day, -1, convert(date, GETDATE()))
(Mà điều kiện cụ thể là đơn hàng vừa được tạo hôm qua, chỉ lấy những đơn hàng mới tạo hôm qua thôi)
Thì khi đó, DBMS sẽ trả ra kết quả là một dòng dữ liệu Order, của khách hàng tên Hà, có trạng thái là Active.
Nghĩa là mình dòm vô một phát là mình biết được tiến trình của đơn hàng đã được xử lý đến bước active. Active nghĩa là đã xử lý xong, và sẵn sàng xuất kho, giao cho khách hàng.
Điều này cũng giống như việc ông Manager trả lời mình là: “ok đã sẵn sàng giao” vậy 
…
Vậy nôm na, SQL là ngôn ngữ để chúng ta nói chuyện với DBMS, và để lấy data mà chúng ta mong muốn. Câu hỏi tiếp theo: BA dùng SQL trong những việc cụ thể nào?
3. BA dùng SQL trong những việc cụ thể nào?
Trước hết, mình cần làm rõ 2 giai đoạn sau.
Đối với những khách hàng còn “trong trắng” và chưa từng sử dụng qua bất kỳ giải pháp công nghệ nào, BA chúng ta sẽ nhúng tay vào cả 2 quá trình:
- Trước khi có data
- Và sau khi có data.
Trước khi có data nghĩa là chúng ta (tức team dự án, gồm: PM, BA, Dev, QA, QC…) sẽ làm một phần mềm, có những tính năng A, B, C, D…, mà sau khi sử dụng phần mềm này, khách hàng sẽ có một lượng data nhất định.
Sau đó sang giai đoạn khi đã có data, chúng ta sẽ xào nấu những data này, rồi bày biện, sắp xếp nó thành những Report và Dashboard có ý nghĩa cho khách hàng. Để họ dòm vào một phát là có đúng ngay thông tin mà họ cần. Từ đó, họ có thể làm ABC, XYZ gì đó tiếp là tùy ý họ
Thông thường mình thấy: BA sẽ tham gia vào giai đoạn (1) nhiều hơn là giai đoạn (2).
Nếu có giai đoạn (2) thì chỉ là làm những dashboard và report không quá phức tạp, và theo đúng nhu cầu hiện tại của khách hàng.
Nhưng business thì luôn thay đổi. Khách hàng luôn có nhu cầu xào nấu dữ liệu theo nhiều chiều kích khác nhau, để cung cấp nhiều hơn thông tin cho họ, ở nhiều khía cạnh.
Nên ở giai đoạn này, thường thì khách hàng họ sẽ cần một người chuyên hơn về data như Business Intelligent Developer, hoặc Data Analyst để giúp họ giải quyết những bài toán bằng lượng data mà họ đang có.
Quay lại với BA (ở giai đoạn 1 – trước khi có data), mình sẽ note lại những thứ mà BA sẽ làm với SQL trong suốt quá trình dự án.
3.1. Đồng hành cùng Dev trong quá trình coding
Trong quy trình làm dự án, rồi cũng sẽ tới đoạn anh em Developer ngồi code từng tính năng một. Lúc này, việc chui xuống database lấy data là một điều rất cần thiết để BA giúp Dev kiểm tra lại những tính năng vừa mới code xong.
Ví dụ có một tính năng: Khi sales vừa tạo mới khách hàng, hệ thống sẽ tự động tạo dữ liệu chiết khấu mặc định và dữ liệu Customer Reference cho khách hàng này, theo công thức ABCXYZ…
Thì ngay khi Dev code xong tính năng này, anh em BA có thể hỗ trợ test bằng việc dùng SQL tạo dữ liệu khách hàng và query các dữ liệu liên quan như Chiết khấu mặc định và Customer Reference, để xem thử hệ thống đã tạo theo đúng công thức ABCXYZ quy định chưa.
Do team mình không có QC (vì hàm lượng test không quá lớn), nên thường thì BA (hay Functional Consultant) sẽ đảm nhiệm luôn vai trò testing. Mặc dù khi Dev code xong một tính năng, thường họ cũng sẽ tự kiểm tra lại theo cách của họ.
Tuy nhiên đây là cách giúp BA theo sát được công việc của anh em Developer, từ đó hiểu dự án và hỗ trợ anh em nhiều hơn trong giai đoạn development.
Ngoài ra, nếu anh em làm Product Owner thì có thể dùng SQL để chui xuống database kiểm tra dữ liệu xem thử đã chạy đúng chưa. Cũng là một cách rất nên làm trong quá trình UAT khi nghiệm thu dự án, thay vì chỉ xem dữ liệu trên lớp front-end thì quá là… rủi ro.
3.2. Công cụ đắc lực trong giai đoạn Transition
Giai đoạn transition là khi anh em đã làm xong phần mềm, và đưa phần mềm vào triển khai cho khách hàng sử dụng.
Giai đoạn này sẽ có rất nhiều thứ búa lua xua phát sinh trong quá trình training, support user sử dụng sau Go-live, hay thậm chí là trao đổi về các yêu cầu mới phát sinh.
Đây là giai đoạn mà nếu BA tận dụng SQL một cách hiệu quả, anh em sẽ được lợi rất rất nhiều trong giai đoạn này.
Ví dụ trong các buổi training end-user.
Hệ thống thường sẽ có một số tính năng kiểu như: User tạo record A >> đứng trên record A, User tạo tiếp record B >> nhấn nút cái bụp >> hệ thống tự động tạo record C dựa trên thông tin của A và B. Mà màn hình không hiển thị record C này cho user thấy.
Vậy tình huống phát sinh là khi: anh em muốn training cho user một cách dễ hiểu hơn, cung cấp cho họ một bức tranh tổng quan hơn.
Thay vì chỉ nói: “…bla…bla…sau khi mọi người tạo record A, record B, hệ thống sẽ tự động tạo record C dựa trên thông tin từ A và B nè…” một cách sáo rỗng, khó mường tượng; thì mình sẽ minh họa bằng cách:
- Tạo dữ liệu A >> tạo dữ liệu B
- >> show cho user thấy thông tin của A và B trên front-end.
- >> chui xuống SQL, query ra dữ liệu C vừa được tạo tự động dựa trên A và B.
- Và cho họ thấy rõ tận mắt các trường dữ liệu của record C này ngay dưới database.
Từ đó, mình dễ dàng highlight được cho user những điểm cần chú ý hơn trong quá trình tạo A, và B; vì nó sẽ ảnh hưởng trực tiếp đến dữ liệu C phát sinh trong database.
…
Hoặc gần đây nhất mình có gặp một issue nhỏ phát sinh sau go-live. Mà căng thẳng hơn nữa là phát sinh ngay thời điểm nhạy cảm: khách hàng chuẩn bị ký thanh lý hợp đồng.
Số là khách hàng họ không push Order từ CRM qua hệ thống ERP của họ được. Hệ thống hiển thị thông báo là: mã địa điểm giao hàng không tồn tại.
(địa điểm giao hàng là các record trong table Territory, với key là Location Code)
Khách hàng thì cứ ì xèo lên báo là hệ thống bị lỗi, chưa work được các kiểu. Nói chung mình nghe cũng hơi ngứa nách vì chưa rõ cái gì hết mà kết luận một câu nghe xanh rờn. Rồi nói bên mình thiết kế dữ liệu Location Code bị sai kiểu dữ liệu này nọ.
Lúc đó mình mới xuống database, query đơn hàng đó ra (với những thông tin họ cung cấp), thì phát hiện ra cấu trúc của table Territory có đến 2 column Location Code mới ghê. Một kiểu number, một kiểu string.
Mà ác nghiệt cái là Location Code kiểu number nó nằm chình ình trên form màn hình, còn dữ liệu Location Code kiểu string nằm dưới database, chưa được kéo lên. Trong khi dữ liệu họ đang cần nhập vô là kiểu string. Nên bên khách hàng mới bảo bên mình thiết kế sai kiểu dữ liệu tùm lum tùm la.
Phát hiện nguyên nhân: BA trước của dự án maintain chỗ này không kỹ (nói đúng ra là ẩu), dữ liệu Location Code kiểu number không dùng nữa, mà không bỏ ra form. Trong khi dữ liệu Location Code kiểu string là mới nhất theo yêu cầu, lại không được kéo lên form màn hình.
Problem solved: Kéo Location Code kiểu string lên form. Khách hàng nhập mã Location Code cho Territory (địa chỉ giao hàng trong đơn hàng) >> push đơn hàng thành công qua ERP >> mọi chuyện êm đẹp >> ký thanh lý hợp đồng cái rẹt.
…
Từ ví dụ trên mới thấy, nếu không query data một cách chi tiết và rõ ràng nhất, sẽ rất khó để phát hiện ra root cause để giải quyết vấn đề. Trong khi giai đoạn Transition luôn là giai đoạn nhạy cảm, và chuyện phát sinh issue cũng như lời qua tiếng lại giữa 2 bên cũng không ít.
Lúc này chỉ còn một cách là dựa vào tính chân thật của data để giải quyết mà thôi. Và để lấy data từ database, anh em BA cần biết SQL.
3.3. Data Analysis
Đây là 1 trong 11 phương pháp moi móc thông tin của BA.
Mình từng làm một dự án quản lý dịch vụ sân bãi máy bay. Khách hàng có yêu cầu tích hợp hệ thống đang làm, với hệ thống quản lý các sự cố xảy ra tại sân bay của họ (tạm gọi là hệ thống A BỜ CỜ).
Vì bản chất khách hàng cũng chưa biết hướng tích hợp như thế nào cho hiệu quả. Nên họ mới gửi cấu trúc database của hệ thống A BỜ CỜ, kèm một số sample data để bên mình hình dung và đề xuất hướng mapping như thế nào cho hợp lý.
Tất nhiên là task này không chỉ mình BA làm mà cả team phải cùng ngồi lại và phân tích.
Nếu BA không biết SQL, thì rõ ràng là rất khó để hình dung các table được tổ chức như thế nào, và khó có thể tự mình query được data theo luồng suy nghĩ mà mình đang có trong đầu.
…
Hoặc đối với các dự án maintain, khi BA vô dự án mà không đủ document để hiểu về hệ thống, thì việc dùng SQL để query data cũng là một cách hay để học và hiểu hơn về hệ thống mình đang maintain.
3.4. Đụng phát là có ngay thông tin
Đây là một công dụng thường thấy nhất khi BA dùng SQL. Đối với BA ở client, hoặc Product Owner, việc lấy data lên để theo dõi là thường xuyên.
Đó có thể là yêu cầu từ sếp, từ các phòng ban hoặc thậm chí từ chính bản thân mình muốn theo dõi một số thông tin trên hệ thống. Khi đó, mình hoàn toàn có thể tự tin dùng SQL để lấy bất cứ data gì mình cần, mà không phải phụ thuộc vào anh em đì-ve-lốp-pơ, kaka.
Hoặc đối với mình, khi hệ thống Go-Live được độ 2-3 ngày, mình cũng hay query data xem thử mật độ records user tạo có nhiều hay không, user nào đã tạo record, user nào chưa,… Từ đó, có ngay báo cáo về tình hình Go-Live cho sếp 
3.5. Giúp sức làm reporting, và nói cho Dev hiểu bằng ngôn ngữ SQL
Đây là trường hợp hoàn toàn không bắt buộc với BA. Nhưng đối với các dự án bị overload về mặt resources, việc BA bay vô kéo report cũng giúp ích rất nhiều cho team.
Các dự án hồi đó mình làm, mình cũng toàn bay vô kéo report phụ anh em. Mặc dù skill SSRS còn hơi cùi bắp nhưng được đến đâu hay đến đấy 
Thực chất mình nghĩ: BA là người nên chủ động làm reporting cho dự án.
Vì BA là người tiếp cận các stakeholders nhiều nhất; là người nắm rõ requirement từ khách hàng, nên họ sẽ có hướng làm reports theo góc nhìn của business users. Tránh tốn thời gian truyền tải lại cho anh em dev (mặc dù vẫn phải có document rõ ràng).
Tuy nhiên, report nào chuối quá thì cũng phải nhờ anh em Dev ra tay.
Ngoài ra, nhìn vô dataset và các expression mà BA làm phần nào cũng giúp Dev hiểu được yêu cầu của report này là gì, mà không cần phải diễn đạt lại chi cho dài dòng, hehe.
…
Trên là những ứng dụng của SQL mà mình – một người BA đã áp dụng trong các dự án phần mềm từ trước đến giờ. Mình tin là còn rất nhiều những thứ khác nữa, mà anh em có thể dùng SQL để phục vụ cho công việc hằng ngày.
Tuy nhiên, SQL thì cũng chỉ là điều kiện cần, điều kiện đủ là…
4. SQL chỉ là điều cần?
Suy cho cùng thì SQL cũng chỉ là công cụ, cái quan trọng nhất là anh em:
- Phải hiểu được cấu trúc dữ liệu
- Và có tư duy giải quyết vấn đề dựa trên data.
Rõ ràng là anh em phải hiểu được dữ liệu được tổ chức như thế nào, thì mới query được. Không thì thứ query được rất tréo que, và chả mang lại ý nghĩa gì cả.
BA (và team) là những người phân tích/ thiết kế hệ thống, nên chuyện hiểu được cấu trúc dữ liệu “behind the scenes” là điều chắc chắn.
- Hệ thống được tổ chức thành bao nhiêu table?
- Relationship giữa các table ra sao?
- Dữ liệu trong các table được định nghĩa như thế nào?
Đó chính là component và relationship, cấu thành bất cứ phần mềm nào.
Xong, một khi đã hiểu được cấu trúc dữ liệu, anh em phải có được tư duy giải quyết vấn đề dựa trên data có trên hệ thống.
Nghĩa là sao?
Tức là khi vấn đề phát sinh, dựa vào cấu trúc dữ liệu và những record hiện có trên hệ thống, anh em có suy ra được điều gì không? Điều này sẽ hình thành nên câu query mà anh em sẽ dùng để lấy data.
Ví dụ nếu khách hàng phản hồi: “Tại sao bây giờ đơn hàng thuộc bộ phận A, kênh X, không chỉnh sửa được đơn giá. Trong khi trước giờ chỉnh được đơn giá bình thường?!?!?”
Khách hàng họ nói: “trước giờ chỉnh được giá bình thường”, thì mình sẽ cần xác minh xem thử: những đơn hàng trước giờ có thật sự chỉnh giá được hay không? ==> ra một câu query những đơn hàng thuộc bộ phận A, kênh X, mà đã được chỉnh giá thành công.
Sau khi đã xác minh đúng như khách hàng nói, thì mình sẽ tiếp tục query ra 2 đơn hàng thuộc bộ phận A, kênh X:
- Một chỉnh sửa được giá
- Một không chỉnh sửa được giá
Và bắt đầu so sánh, đối chiếu với nhau, xem thử tại sao dữ liệu này chỉnh được, mà dữ liệu kia không chỉnh được. Từ đó xem thêm Audit Log, check với Dev, và check thêm 1 số dữ liệu trên đơn hàng để làm rõ vấn đề.
Đó là cách mà mình dựa trên data để tư duy, kết hợp với SQL để lấy data, từ đó giải quyết vấn đề.
Và đó cũng là lý do mà tại sao hơn 500 trang BABOK v3.0 – quyển giáo khoa kinh điển của BA, chỉ nhắc đến từ “SQL” duy nhất đúng một lần.
Hơn 250,000 từ nói về nghề BA, một cách quy chuẩn nhất, mà chỉ có 1 từ nhắc về SQL (hay Structured Query Language). Tỉ lệ 0.0004%.
Mình tin rằng điều này nói rõ được một điều: SQL cũng chỉ là công cụ, mấu chốt là cách tư duy lấy data ra để làm gì!
Thành thạo công cụ sẽ giúp mình làm nhanh, nhưng không hiểu bản chất thì sẽ không làm được gì hết.
Ngoài ra, không phải anh em BA nào cũng dùng SQL. Mà nó còn tùy vào công nghệ, vào sản phẩm, giải pháp mà anh em đang làm nữa.
Như mình đang triển khai giải pháp Dynamics 365. Đây là một SaaS của Microsoft, và nó hỗ trợ người dùng query data ngay trên hệ thống ở mức phải nói là… không thể thân thiện hơn được nữa.
Toàn bộ 100% là hỗ trợ giao diện kéo thả, nhưng bên dưới vẫn là lớp FetchXML mô tả đoạn query của người dùng. Hoặc làm Embedded Dataset trong SSRS mình cũng dùng câu Fetch chứ không dùng SQL.
Thực tế thì đoạn FetchXML này nó cũng tương đương với SQL khi anh em query từ một database bất kỳ.
FetchXML <=> SQL
Ngoài ra, tùy giải pháp, tùy tính chất, mà các công ty sẽ chọn các DBMS khác nhau. Với mỗi DBMS nó sẽ có đôi chút khác biệt ở câu query. Nhưng về cơ bản thì tất cả đều dựa trên ngôn ngữ SQL hết, nên anh em cứ yên tâm, nắm SQL là chắc cú nhất.
Ranking của một số DBMS, đọc thêm tạidb-engines
Nói về độ phổ biến thì SQL không cần phải bàn cãi nhiều. Từ Dev, BA, PO, Data Analyst, BI Developer, hay thậm chí là những anh em làm Marketing, HR…, tất cả đều cần SQL cho công việc của mình.
Theo một khảo sát trên Stackoverflow thì SQL là ngôn ngữ phổ biến thứ 2 nếu xếp chung với các ngôn ngữ lập trình khác (mặc dù nó là ngôn ngữ truy vấn dữ liệu, hổng phải ngôn ngữ lập tờ rình).
Nguồn tham khảo từTablePlus
5. Tạm kết
Như tiều đề, bài note này nằm trong phạm vi SQL. Đối với NoSQL, vì tác giả chưa có kinh nghiệm nên chưa dám chém lung tung.
Sau cùng, bài note này sẽ tạm kết ở 2 gạch đầu dòng sau:
Gạch đầu dòng 1: BA không nhất thiết phải biết SQL; nhưng BA phải hiểu được cấu trúc dữ liệu, và có tư duy giải quyết vấn đề dựa trên data.
Gạch đầu dòng 2: Con đường ngắn nhất để đi đến gạch đầu dòng1 là biết sử dụng SQL :)))
Tóm gọn lần 2, BA sẽ dùng SQL cho những việc sau:
- Hỗ trợ Dev trong testing, reporting, và những thứ linh tinh khác.
- Tìm ra root cause để giải quyết vấn đề dựa trên data query được.
- Móc data kịp thời, phục vụ nhiều stakeholders khác nhau.
- Data Analysis – hiểu một hệ thống bất kỳ dựa trên cấu trúc dữ liệu của nó.
Hi vọng qua bài này anh em sẽ có góc nhìn chân thật hơn về bản chất của SQL đối với BA: dùng để làm gì và tại sao phải dùng SQL?
Cảm ơn anh em đã đọc tới đây. Nếu có gì thắc mắc cứ để lại còm men bên dưới cho mình nhé. Bái baiiii.
Tham khảo thêm
Nguồn: thinhnotes.com
