Mở đầu — vì sao bài này quan trọng
Trong suốt khóa học, chúng ta đã dành phần lớn thời gian để học cách thiết kế một data model từ con số không: vẽ entity, gắn attribute, chọn primary key, chuẩn hóa, rồi đổ ra physical schema. Nhưng nếu bạn nhìn vào thực tế công việc của một Business Analyst, sự thật phũ phàng là: bạn hiếm khi được thiết kế từ đầu. Phần lớn thời gian, bạn bước vào một dự án đã chạy được vài năm, với một database đã có 200 bảng, không ai còn nhớ vì sao cột status_2 lại tồn tại song song với status, và tài liệu (nếu có) thì đã lạc hậu từ ba phiên bản trước.
Kỹ năng đọc và đánh giá một schema có sẵn (reviewing existing schemas) vì thế còn quan trọng hơn kỹ năng vẽ schema mới. Đây là kỹ năng giúp bạn nhanh chóng hiểu một hệ thống lạ, phát hiện rủi ro tiềm ẩn trước khi đề xuất thay đổi, và nói chuyện ngang hàng với đội kỹ thuật thay vì gật gù cho qua. Một BA giỏi đọc schema giống như một bác sĩ giỏi đọc phim X-quang: không chỉ thấy "có gì ở đó", mà còn đọc được câu chuyện đằng sau — vì sao nó thành ra như vậy, và nó đang đau ở đâu.
Bài này sẽ trang bị cho bạn một quy trình review có hệ thống, các tín hiệu cảnh báo cần để ý, và cách biến những gì bạn quan sát được thành một báo cáo đánh giá có giá trị cho dự án.
Khái niệm cốt lõi
Khi nào BA cần review một schema có sẵn?
Có năm bối cảnh điển hình mà bạn sẽ phải mở một database lạ ra và đánh giá:
- Tham gia giữa dự án (joining mid-project): Bạn được điều sang một dự án đang chạy. Để đóng góp được, bạn phải hiểu mô hình dữ liệu hiện tại trước khi viết bất kỳ requirement nào.
- Kế thừa hệ thống legacy (inheriting legacy system): Công ty quyết định nâng cấp hoặc thay thế một hệ thống cũ. Bạn phải hiểu cái cũ trước khi định nghĩa cái mới.
- Đánh giá tích hợp với nhà cung cấp (vendor integration assessment): Doanh nghiệp mua một phần mềm của bên thứ ba và cần tích hợp với hệ thống nội bộ. Bạn phải đọc schema (hoặc data model do vendor cung cấp) để đánh giá mức độ khớp.
- Đánh giá trước khi migration (pre-migration assessment): Trước khi chuyển dữ liệu sang hệ thống mới, bạn phải hiểu cấu trúc nguồn để lập kế hoạch ánh xạ (mapping).
- Đánh giá định kỳ / audit (architecture review): Một số tổ chức rà soát schema theo chu kỳ để kiểm soát chất lượng dữ liệu và nợ kỹ thuật (technical debt).
Ba lớp cần đánh giá
Khi review một schema, hãy tách bạch ba lớp riêng biệt — đừng trộn lẫn vì mỗi lớp đòi hỏi cách nhìn khác nhau:
- Cấu trúc (structure): Các bảng, cột, kiểu dữ liệu, khóa, quan hệ, ràng buộc. Đây là phần "tĩnh" — đọc được từ DDL.
- Dữ liệu thực tế (data): Nội dung thật trong bảng. Schema có thể nói "cột này NOT NULL" nhưng dữ liệu mới cho bạn biết 40% bản ghi đang chứa chuỗi rỗng
''để né ràng buộc. - Ý đồ nghiệp vụ (intent): Vì sao schema được thiết kế như vậy. Đây là phần khó nhất, thường phải suy luận và phỏng vấn người liên quan.
Khoảng cách giữa "schema nói gì" và "thực tế ra sao"
Đây là khái niệm quan trọng nhất của bài. Một schema được khai báo (declared) thường không phản ánh đúng cách hệ thống vận hành (actual behavior). Vài ví dụ kinh điển:
- Cột
email VARCHAR(255)không có UNIQUE constraint → nghĩa là hệ thống cho phép email trùng, dù nghiệp vụ nói "mỗi khách một email". - Quan hệ cha–con tồn tại trên thực tế nhưng không có foreign key ràng buộc → integrity được "kỳ vọng" do code application giữ, không phải database. Đây là nguồn của vô số bản ghi mồ côi (orphan records).
- Cột
is_deletedcho thấy hệ thống dùng soft delete, nhưng nếu nửa số query không lọcis_deleted = 0thì báo cáo sẽ sai.
Tình huống thực tế
Tình huống 1 — Vinaphar và database "đa thế hệ"
Một chuỗi nhà thuốc giả định tên Vinaphar với 120 cửa hàng tại miền Nam thuê bạn tham gia dự án xây hệ thống báo cáo doanh thu tập trung. Database POS hiện tại đã chạy 7 năm, qua ba đời lập trình viên.
Khi mở schema bảng transactions, bạn thấy: total, total_amount, và grand_total — ba cột cùng tồn tại. Hỏi đội kỹ thuật, không ai dám xóa cột nào vì "sợ chỗ khác đang dùng". Bạn viết một query thống kê: cột total chỉ có dữ liệu cho bản ghi trước 2021, total_amount cho 2021–2023, và grand_total từ 2023 đến nay. Hóa ra mỗi đời dev thêm một cột mới thay vì sửa cột cũ.
Diễn giải: Đây là dấu vết của schema evolution không có kỷ luật. Schema (lớp 1) trông như có ba khái niệm tổng tiền, nhưng dữ liệu (lớp 2) tiết lộ chúng là cùng một khái niệm theo thời gian. Nếu bạn viết báo cáo doanh thu mà chỉ SUM(grand_total), bạn mất toàn bộ doanh thu trước 2023.
Bài học: Đừng bao giờ tin tên cột. Luôn kiểm tra phân bố dữ liệu theo thời gian (data profiling) khi thấy các cột nghi ngờ trùng lặp. Với báo cáo, bạn cần một quy tắc gộp (coalesce) đúng: COALESCE(grand_total, total_amount, total).
Tình huống 2 — Tích hợp vendor giao vận ở một sàn TMĐT
Một sàn thương mại điện tử giả định ChợViet tích hợp với một nhà cung cấp dịch vụ giao vận. Vendor gửi cho bạn tài liệu data model PDF 40 trang để bạn đánh giá khả năng tích hợp đơn hàng.
Đọc kỹ, bạn phát hiện bảng shipment của vendor dùng recipient_phone VARCHAR(15) làm khóa định danh khách nhận hàng — không có customer ID riêng. Trong khi đó, hệ thống ChợViet định danh khách bằng customer_id và một khách có thể có nhiều số điện thoại. Tệ hơn, vendor lưu địa chỉ trong một cột text tự do duy nhất address_full, còn ChờViet đã chuẩn hóa thành tỉnh/quận/phường riêng.
Diễn giải: Đây là impedance mismatch — hai mô hình định danh và cấu trúc hóa dữ liệu theo cách khác nhau. Số điện thoại không phải là một natural key tốt (một người đổi số, hai người dùng chung số nhà). Cột địa chỉ tự do của vendor sẽ khiến việc đối soát và phân tích theo khu vực gần như bất khả thi.
Bài học: Khi đánh giá tích hợp vendor, hãy soi ba điểm: (1) cách định danh entity hai bên có khớp không, (2) độ chi tiết (granularity) của dữ liệu, (3) chỗ nào bên này có ràng buộc mà bên kia không có. Kết luận review của bạn không phải "tích hợp được/không được" mà là "tích hợp được với điều kiện xây một lớp ánh xạ địa chỉ và một bảng trung gian map phone–customer".
Tình huống 3 — Pre-migration tại một công ty bảo hiểm
Một công ty bảo hiểm nhân thọ giả định An Phúc Life muốn migrate hệ thống quản lý hợp đồng cũ sang nền tảng mới. Bạn được giao đánh giá schema nguồn trước khi lập kế hoạch.
Bảng policy có cột customer_id tham chiếu sang bảng customer, nhưng không có foreign key. Bạn chạy một query kiểm tra và phát hiện 3.200 hợp đồng trỏ tới customer_id không tồn tại trong bảng customer — đó là các khách hàng đã bị xóa cứng (hard delete) qua nhiều năm. Ngoài ra, cột status chứa tới 14 giá trị khác nhau gồm cả 'Active', 'active', 'ACTIVE', 'còn hiệu lực' và cả khoảng trắng thừa.
Diễn giải: Thiếu foreign key đã tạo ra 3.200 orphan records — những hợp đồng "mồ côi" không biết của ai. Cột status lộn xộn cho thấy không có domain constraint, dữ liệu nhập bằng nhiều nguồn và nhiều ngôn ngữ qua thời gian.
Bài học: Trong pre-migration, referential integrity và data quality là rủi ro số một, không phải cấu trúc bảng. Báo cáo của bạn phải định lượng được: "3.200/85.000 hợp đồng cần xử lý nghiệp vụ trước khi migrate" và "cột status cần một bảng ánh xạ chuẩn hóa về 4 trạng thái chuẩn". Đây là thông tin giúp dự án ước lượng đúng công sức làm sạch dữ liệu — thứ thường bị xem nhẹ và làm vỡ tiến độ migration.
Hướng dẫn từng bước
Dưới đây là quy trình bảy bước bạn có thể áp dụng cho bất kỳ schema lạ nào.
Bước 1 — Thu thập "bản đồ". Xin DDL (lệnh CREATE TABLE) của toàn bộ schema, hoặc tự sinh ERD bằng công cụ reverse-engineering (ví dụ DBeaver, dbdiagram import, hoặc tính năng "generate diagram from database"). Mục tiêu: có một bức tranh tổng thể trên một màn hình.
Bước 2 — Định vị các entity trung tâm. Tìm những bảng có nhiều quan hệ nhất — thường là customer, order, product, account. Đây là "hub" của hệ thống. Hiểu các hub này trước, đừng sa lầy vào bảng cấu hình lặt vặt.
Bước 3 — Lập bản đồ quan hệ và khóa. Với mỗi bảng trung tâm, xác định primary key, các foreign key, và quan hệ (1-1, 1-N, N-N). Đặc biệt ghi chú: quan hệ nào có FK thật sự, quan hệ nào chỉ là "ngầm hiểu" qua tên cột mà không có ràng buộc.
Bước 4 — Profiling dữ liệu thực. Đây là bước phân biệt BA giỏi với BA hời hợt. Với mỗi cột quan trọng, chạy thống kê: tỷ lệ NULL, số giá trị phân biệt (distinct count), min/max, các giá trị xuất hiện nhiều nhất, độ dài chuỗi. Ví dụ: SELECT status, COUNT(*) FROM policy GROUP BY status ORDER BY 2 DESC. Bước này lộ ra mọi sự bừa bộn ẩn giấu.
Bước 5 — Kiểm tra tính toàn vẹn. Đếm orphan records (con trỏ tới cha không tồn tại), kiểm tra trùng lặp ở các cột lẽ ra phải unique, tìm bản ghi vi phạm business rule hiển nhiên (ví dụ ngày kết thúc trước ngày bắt đầu).
Bước 6 — Truy vết ý đồ. Phỏng vấn người còn nắm hệ thống, đọc commit history nếu có, đối chiếu với tài liệu cũ. Câu hỏi vàng: "Vì sao chỗ này lại được thiết kế như vậy?" Đừng vội phán xét — nhiều quyết định kỳ lạ có lý do nghiệp vụ chính đáng đã bị lãng quên (Chesterton's Fence: đừng dỡ hàng rào khi chưa biết vì sao nó được dựng).
Bước 7 — Tổng hợp báo cáo đánh giá. Trình bày theo ba mục: (a) những điều đang ổn, (b) rủi ro được phân loại theo mức độ và định lượng bằng con số, (c) khuyến nghị kèm ước lượng công sức. Luôn gắn rủi ro với tác động nghiệp vụ, không phải chỉ với "vi phạm chuẩn lý thuyết".
Lỗi thường gặp & mẹo
Lỗi 1 — Tin schema thay vì kiểm chứng dữ liệu. Schema khai báo là lời hứa, dữ liệu là sự thật. Luôn profiling trước khi kết luận.
Lỗi 2 — Phán xét quá sớm. Mới thấy một bảng không chuẩn hóa đã vội kết luận "thiết kế tệ". Có khi đó là denormalization có chủ đích vì lý do hiệu năng. Hãy hỏi trước khi chê.
Lỗi 3 — Sa vào tiểu tiết, mất bức tranh lớn. Dành ba ngày phân tích một bảng log ít quan trọng trong khi chưa hiểu luồng đơn hàng chính. Luôn đi từ hub ra ngoài.
Lỗi 4 — Báo cáo định tính, không định lượng. Viết "dữ liệu status hơi lộn xộn" thì vô dụng. Viết "status có 14 biến thể, 23% bản ghi cần làm sạch" thì giúp ra quyết định.
Lỗi 5 — Bỏ qua các quan hệ ngầm. Nhiều hệ thống legacy giữ integrity bằng code application, không bằng FK. Đừng cho rằng "không có FK nghĩa là không có quan hệ".
Mẹo: Tạo một "data dictionary tái dựng" trong lúc review — ghi lại ý nghĩa thật của từng cột quan trọng khi bạn khám phá ra. Tài liệu này thường có giá trị hơn cả tài liệu gốc đã lạc hậu, và là di sản bạn để lại cho dự án.
Mẹo: Để ý các "code smell" trong schema: cột tên field1, field2, cột chứa danh sách ngăn cách bằng dấu phẩy (vi phạm 1NF), bảng tên temp_, backup_, new_ còn sót trong production. Mỗi cái là một câu chuyện cần hỏi.
Bài tập thực hành
Lấy một schema thật bạn có quyền truy cập (hệ thống ở công ty bạn, hoặc một open dataset như database mẫu Sakila/Chinook), và thực hiện:
- Vẽ lại ERD của 5 bảng trung tâm nhất bằng công cụ reverse-engineering, đánh dấu rõ quan hệ nào có FK thật, quan hệ nào chỉ ngầm hiểu.
- Profiling ít nhất 3 cột quan trọng: thống kê tỷ lệ NULL, distinct count, và top 5 giá trị phổ biến. Ghi lại bất kỳ điều gì gây bất ngờ.
- Săn orphan records: chọn một quan hệ cha–con và viết query đếm số bản ghi con trỏ tới cha không tồn tại.
- Tìm một "code smell" trong schema và đặt ra ba câu hỏi bạn sẽ hỏi người thiết kế để hiểu ý đồ.
- Viết một báo cáo đánh giá nửa trang theo cấu trúc ba mục (đang ổn / rủi ro định lượng / khuyến nghị) như thể trình bày cho quản lý dự án.
Tóm tắt
Reviewing existing schemas là kỹ năng nền tảng của BA dữ liệu, bởi trong thực tế bạn đến với hệ thống đã có sẵn nhiều hơn là thiết kế mới. Năm bối cảnh chính cần review gồm: tham gia giữa dự án, kế thừa legacy, đánh giá tích hợp vendor, đánh giá trước migration, và audit định kỳ. Hãy luôn tách ba lớp — cấu trúc, dữ liệu thực, và ý đồ nghiệp vụ — và nhớ rằng giá trị lớn nhất nằm ở chỗ phát hiện khoảng cách giữa "schema nói gì" và "thực tế ra sao".
Quy trình bảy bước — từ thu thập bản đồ, định vị hub, lập bản đồ quan hệ, profiling dữ liệu, kiểm tra toàn vẹn, truy vết ý đồ, đến tổng hợp báo cáo — cho bạn một cách tiếp cận có kỷ luật. Ba bài học cốt lõi từ các tình huống thực tế: đừng tin tên cột (Vinaphar), soi kỹ cách định danh và độ chi tiết khi tích hợp (ChợViet), và đặt referential integrity cùng data quality lên đầu khi chuẩn bị migration (An Phúc Life). Và nguyên tắc bao trùm tất cả: định lượng mọi rủi ro bằng con số, và luôn hỏi "vì sao" trước khi đề xuất thay đổi.