Bài 30 — Data Migration Modeling — Data Modeling and ERD Mastery

Mở đầu — vì sao bài này quan trọng

Trong sự nghiệp của một Business Analyst (BA), bạn sẽ gặp một loại dự án mà ai cũng sợ nhưng không tránh được: di chuyển dữ liệu (data migration). Đó là khi doanh nghiệp thay hệ thống cũ bằng hệ thống mới — ví dụ chuyển từ một phần mềm kế toán tự viết sang SAP, từ một core banking cũ kỹ sang một nền tảng hiện đại, hay từ file Excel rời rạc sang một ERP tập trung. Nghe có vẻ chỉ là "copy dữ liệu từ A sang B", nhưng thực tế đây là nơi vô số dự án CNTT thất bại hoặc trễ hạn nhiều tháng.

Vì sao? Vì dữ liệu trong hệ thống cũ hầu như không bao giờ "sạch" và không bao giờ khớp hoàn hảo với cấu trúc hệ thống mới. Một khách hàng có thể tồn tại hai lần với hai cách viết tên khác nhau. Một trường ngày sinh có thể chứa giá trị "00/00/1900". Một mã sản phẩm bên cũ là chuỗi tự do, bên mới bắt buộc theo định dạng chuẩn. Nếu không có ai mô hình hóa và lập kế hoạch cho việc chuyển đổi này, đội kỹ thuật sẽ "chữa cháy" từng trường hợp một cách hỗn loạn.

Đó chính là vai trò của BA. Bài này tập trung riêng vào mô hình hóa dữ liệu cho việc di chuyển (data migration modeling) — tức cách bạn thiết kế bản đồ ánh xạ (mapping), mô hình dữ liệu trung gian, và quy tắc chuyển đổi. Lưu ý: bài này không lặp lại nội dung về Migration Planning và Data Quality tổng quát (đã có ở Bài 3), cũng không đi sâu vào Schema Evolution (Bài 44). Ở đây ta tập trung vào phần "modeling" — sản phẩm cụ thể mà một BA phải tạo ra để cuộc di chuyển dữ liệu diễn ra suôn sẻ.

Khái niệm cốt lõi

Data migration là gì dưới góc nhìn dữ liệu

Data migration là quá trình đưa dữ liệu từ nguồn (source) sang đích (target) thông qua một loạt bước chuyển đổi. Mô hình hóa di chuyển dữ liệu nghĩa là bạn mô tả một cách có cấu trúc: dữ liệu nào đi từ đâu, đến đâu, biến đổi ra sao, và những quy tắc nào quyết định việc chấp nhận hay loại bỏ một bản ghi.

Có ba mô hình dữ liệu mà BA cần phân biệt trong một dự án di chuyển:

Source data model — cấu trúc dữ liệu của hệ thống cũ (thường lộn xộn, ít chuẩn hóa, đôi khi không có tài liệu).
Target data model — cấu trúc dữ liệu của hệ thống mới (thường đã chuẩn hóa, có ràng buộc nghiêm ngặt).
Staging / transformation model — mô hình trung gian, nơi dữ liệu được làm sạch, chuẩn hóa và biến đổi trước khi nạp vào đích.

Tư duy cốt lõi cần nhớ: bạn không chuyển trực tiếp từ source sang target. Bạn luôn đi qua một vùng trung gian (staging) để kiểm soát chất lượng. Đây là điểm khác biệt giữa một BA chuyên nghiệp và một người chỉ nghĩ "kéo thả là xong".

Bốn giai đoạn của di chuyển dữ liệu

Một dự án migration thường có bốn giai đoạn, và BA tham gia sâu nhất ở hai giai đoạn đầu:

Assessment (Đánh giá) — Khảo sát hệ thống nguồn. Có bao nhiêu bảng, bao nhiêu bản ghi, chất lượng ra sao, ai là chủ dữ liệu. Đây là lúc bạn lập source data profiling (lập hồ sơ dữ liệu nguồn): đếm số dòng, tỷ lệ trường rỗng, các giá trị bất thường.
Mapping (Ánh xạ) — Sản phẩm quan trọng nhất của BA: một bảng ánh xạ trường-sang-trường (field-to-field mapping) kèm quy tắc chuyển đổi. Đây là "trái tim" của mô hình hóa migration.
Migration / ETL — Đội kỹ thuật xây dựng quy trình Extract–Transform–Load dựa trên mapping của bạn.
Validation & Reconciliation (Kiểm tra & đối soát) — So sánh nguồn và đích để chứng minh không mất dữ liệu, không sai lệch.

Mapping specification — tài liệu trung tâm

Tài liệu ánh xạ là sản phẩm cốt lõi. Một dòng mapping điển hình gồm các cột:

Source table.field	Target table.field	Transformation rule	Default value	Notes

Ví dụ một dòng: KHACHHANG.HoTen → customers.full_name | "Chuẩn hóa hoa/thường theo Title Case, cắt khoảng trắng thừa" | (không) | "Tên gốc có thể chứa cả mã KH ở cuối, cần tách".

Bên cạnh ánh xạ trực tiếp 1-1, bạn còn phải xử lý các kiểu phức tạp hơn:

Many-to-one: hai trường nguồn gộp thành một trường đích (ví dụ Ho + Ten → full_name).
One-to-many: một trường nguồn tách thành nhiều trường đích (ví dụ trường địa chỉ tự do tách thành street, ward, district, province).
Lookup / mã hóa lại: giá trị nguồn được tra cứu sang giá trị chuẩn của hệ thống mới (ví dụ "Nam"/"Nữ" → M/F, hoặc mã tỉnh cũ → mã tỉnh theo chuẩn mới).
Derived: giá trị đích được tính toán (ví dụ account_status được suy ra từ ngày giao dịch cuối cùng).

Transformation rules và xử lý ngoại lệ

Mỗi quy tắc chuyển đổi cần trả lời: nếu dữ liệu nguồn không hợp lệ thì làm gì? Có ba chiến lược phổ biến mà BA phải quyết định cùng nghiệp vụ:

Reject — loại bản ghi ra "danh sách lỗi" để xử lý thủ công sau.
Default — gán giá trị mặc định (ví dụ ngày sinh không hợp lệ → NULL thay vì 01/01/1900).
Cleanse — tự động làm sạch theo quy tắc (ví dụ chuẩn hóa số điện thoại +84 về 0).

Migration data model như một cấu trúc dữ liệu

Đừng quên: bản thân quá trình migration cũng cần một mô hình dữ liệu riêng để quản lý. Bạn thường thiết kế thêm các bảng phụ trợ:

Crosswalk / mapping table — bảng ánh xạ ID cũ sang ID mới (ví dụ legacy_customer_id ↔ new_customer_id). Cực kỳ quan trọng để giữ liên kết khi khóa thay đổi.
Migration log / error table — ghi lại mọi bản ghi bị loại, lý do, để đối soát.
Reconciliation table — bảng đối chiếu số lượng, tổng tiền giữa nguồn và đích.

Tình huống thực tế

Ví dụ 1 — Ngân hàng TMCP chuyển đổi core banking

Một ngân hàng thương mại cổ phần tại TP.HCM (gọi là Ngân hàng Đông Phương) quyết định thay core banking cũ tự phát triển từ năm 2008 bằng một nền tảng quốc tế. Họ có khoảng 2,3 triệu khách hàng và 4,1 triệu tài khoản.

Khi BA làm assessment, họ phát hiện vấn đề kinh điển: trong hệ thống cũ, một khách hàng cá nhân có thể có nhiều bản ghi do mỗi lần mở sản phẩm mới (tiết kiệm, vay, thẻ) lại tạo một "hồ sơ khách hàng" riêng. Hệ thống mới yêu cầu mô hình một khách hàng — nhiều tài khoản (one-to-many) với CMND/CCCD là khóa định danh duy nhất.

BA phải thiết kế một bước deduplication (gộp trùng) trong staging: nhóm các bản ghi theo số CCCD, chọn bản ghi "vàng" (golden record) làm chuẩn dựa trên quy tắc nghiệp vụ — ưu tiên hồ sơ có giao dịch gần nhất và đầy đủ thông tin nhất. Đồng thời họ xây bảng crosswalk: mỗi legacy_customer_id cũ phải trỏ về một new_customer_id mới, để khi chuyển tài khoản và lịch sử giao dịch, các liên kết không bị đứt gãy.

Bài học: Khi mô hình nguồn và đích khác nhau về quan hệ (cũ là nhiều-nhiều ngầm, mới là một-nhiều rõ ràng), bước nặng nhất không phải copy mà là deduplication và xây crosswalk. Nếu bỏ qua, ngân hàng sẽ có một khách hàng hiện ra ba lần trên app, một cơn ác mộng về trải nghiệm và tuân thủ.

Ví dụ 2 — Chuỗi bán lẻ chuyển từ Excel sang ERP

Một chuỗi cửa hàng mỹ phẩm có 38 chi nhánh (giả định: Mỹ phẩm Hương Sen) quản lý tồn kho bằng các file Excel rời rạc, mỗi chi nhánh một file. Họ triển khai ERP tập trung. Dữ liệu sản phẩm là điểm nóng: cùng một thỏi son nhưng mỗi chi nhánh đặt một mã khác nhau ("Son MAC ruby" vs "MAC-RubyWoo" vs "son đỏ MAC").

BA xây một bảng lookup chuẩn hóa sản phẩm trong staging: ánh xạ hàng nghìn tên tự do về một danh mục SKU chuẩn duy nhất. Quy tắc transformation gồm: cắt khoảng trắng, bỏ dấu để so khớp gần đúng, rồi đối chiếu thủ công những trường hợp không tự khớp được (đưa vào error table cho nhân viên nghiệp vụ duyệt).

Con số thực tế: trong 12.400 dòng sản phẩm gốc, khoảng 70% tự ánh xạ được nhờ quy tắc, 30% còn lại (~3.700 dòng) phải duyệt tay. BA ước lượng công sức này ngay từ giai đoạn mapping nên dự án không bị "vỡ" tiến độ.

Bài học: Khi nguồn là dữ liệu nhập tay tự do, đừng kỳ vọng ánh xạ tự động 100%. Hãy thiết kế sẵn đường đi cho dữ liệu không khớp (error/exception table) và ước lượng công sức xử lý thủ công ngay từ đầu. Đây là khác biệt giữa kế hoạch thực tế và kế hoạch viển vông.

Ví dụ 3 — Migration thử nghiệm theo lô (pilot migration)

Một công ty bảo hiểm nhân thọ (giả định: Bảo hiểm An Tâm) chuyển 1,8 triệu hợp đồng sang hệ thống mới. Thay vì chuyển hết một lần, BA đề xuất chia thành các đợt: đợt thử (pilot) 5.000 hợp đồng của một chi nhánh, rồi mới mở rộng.

Trong đợt pilot, đội phát hiện mô hình ngày tháng sai lệch: hệ thống cũ lưu ngày theo định dạng DD/MM/YYYY dạng text, có nhiều giá trị "29/02" của năm không nhuận. Quy tắc transformation ban đầu làm tròn về 01/03, nhưng nghiệp vụ phản đối vì sai ngày hiệu lực hợp đồng. BA điều chỉnh: những bản ghi ngày không hợp lệ được đưa vào error table để nghiệp vụ tra hồ sơ giấy.

Bài học: Mô hình hóa migration không phải làm một lần là xong. Pilot migration giúp lộ ra những lỗ hổng trong transformation rule trước khi đổ vỡ trên toàn bộ 1,8 triệu bản ghi. Reconciliation sau mỗi đợt (đếm số hợp đồng, tổng giá trị bảo hiểm) là bằng chứng để nghiệp vụ ký nghiệm thu.

Hướng dẫn từng bước

Đây là quy trình bạn có thể áp dụng cho một dự án di chuyển dữ liệu:

Lập hồ sơ dữ liệu nguồn (source profiling). Lấy mẫu và thống kê: số bản ghi mỗi bảng, tỷ lệ trường rỗng, các giá trị riêng biệt, định dạng bất thường. Mục tiêu là hiểu thực trạng, không tin vào tài liệu cũ.

Hiểu rõ mô hình dữ liệu đích. Đọc kỹ ràng buộc của hệ thống mới: trường nào bắt buộc, khóa nào duy nhất, kiểu dữ liệu nào, danh mục mã hóa nào. Đây là "khuôn" mà dữ liệu nguồn phải khớp vào.

Xây bảng mapping field-to-field. Với mỗi trường đích, xác định nguồn của nó: lấy từ trường nào, gộp/tách ra sao, default là gì. Đánh dấu các trường đích không có nguồn (cần default hoặc nhập mới) và các trường nguồn bị bỏ (ghi rõ lý do để tránh tranh cãi sau này).

Viết transformation rules chi tiết. Mỗi quy tắc nêu rõ logic và cách xử lý ngoại lệ (reject / default / cleanse). Quy tắc phải đủ rõ để lập trình viên code mà không cần đoán.

Thiết kế các bảng phụ trợ. Crosswalk (ánh xạ ID cũ–mới), error/log table, reconciliation table. Đây là mô hình dữ liệu của chính quá trình migration.

Định nghĩa tiêu chí đối soát. Trước khi chạy, thống nhất với nghiệp vụ: đối soát cái gì là "đạt"? Thường gồm số lượng bản ghi (record count), tổng các trường tiền tệ (control totals), và kiểm tra mẫu (spot check) một số bản ghi tiêu biểu.

Chạy pilot và lặp lại. Migration một lô nhỏ, đối soát, sửa rule, rồi mới mở rộng. Lặp cho đến khi tỷ lệ lỗi nằm trong ngưỡng chấp nhận được.

Cutover và đối soát cuối. Đợt chuyển chính thức, đóng băng hệ thống cũ, đối soát toàn bộ, và lưu báo cáo làm bằng chứng nghiệm thu.

Lỗi thường gặp & mẹo

Lỗi 1 — Coi nhẹ chất lượng dữ liệu nguồn. Nhiều BA giả định dữ liệu cũ "chắc là ổn". Thực tế hiếm khi ổn. Mẹo: luôn profiling trước, đừng tin tài liệu — hãy tin con số thực.

Lỗi 2 — Mapping thiếu xử lý ngoại lệ. Bảng mapping chỉ ghi "trường A → trường B" mà không nói "nếu A rỗng / sai định dạng thì sao". Mẹo: mỗi dòng mapping bắt buộc có cột "xử lý khi không hợp lệ".

Lỗi 3 — Quên crosswalk khóa. Khi ID thay đổi giữa hệ thống cũ và mới mà không lưu bảng ánh xạ, bạn sẽ mất khả năng truy vết và các quan hệ (giao dịch, hợp đồng) bị đứt. Mẹo: luôn thiết kế crosswalk table ngay từ đầu.

Lỗi 4 — Big bang thay vì incremental. Cố chuyển toàn bộ một lần dễ dẫn đến sụp đổ quy mô lớn. Mẹo: ưu tiên pilot rồi mở rộng theo lô; chỉ làm big bang khi dữ liệu nhỏ và sạch.

Lỗi 5 — Không đối soát hoặc đối soát muộn. Chuyển xong mà không chứng minh được "đủ và đúng" thì nghiệp vụ không dám nghiệm thu. Mẹo: định nghĩa tiêu chí reconciliation trước khi chạy, không phải sau.

Mẹo bổ sung: Hãy coi mọi trường nguồn bị bỏ là một quyết định có chủ đích, được ghi lại và ký duyệt. Câu hỏi "sao dữ liệu này không thấy trên hệ thống mới?" sẽ xuất hiện sau go-live, và tài liệu mapping của bạn là câu trả lời.

Bài tập thực hành

Bối cảnh: Một phòng khám đa khoa chuyển từ phần mềm quản lý cũ (lưu trong Access) sang hệ thống bệnh án điện tử mới. Bảng BENHNHAN nguồn có các trường: MaBN (text tự do), HoVaTen (gộp họ tên), NgaySinh (text, nhiều giá trị "00/00/0000"), GioiTinh ("Nam"/"Nữ"/để trống), DiaChi (địa chỉ tự do một dòng), SDT (có cả +84 lẫn 0).

Hệ thống đích có bảng patients: patient_id (UUID mới), last_name, first_name, date_of_birth (DATE, cho phép NULL), gender (M/F/U), province, district, ward, phone (chuẩn 0xxxxxxxxx).

Yêu cầu:

Lập bảng mapping field-to-field cho cả 6 trường nguồn, ghi rõ kiểu ánh xạ (1-1, gộp, tách, lookup) và transformation rule.
Với mỗi trường, ghi rõ chiến lược xử lý khi dữ liệu không hợp lệ (reject / default / cleanse).
Thiết kế cấu trúc bảng crosswalk ánh xạ MaBN cũ sang patient_id mới.
Liệt kê 3 tiêu chí reconciliation bạn sẽ dùng để chứng minh migration thành công.

Gợi ý tự đánh giá: lời giải tốt sẽ tách HoVaTen thành last_name/first_name (lưu ý họ tên Việt Nam phức tạp, sẽ học kỹ ở Bài 26), tách DiaChi thành tỉnh/huyện/xã, lookup giới tính sang M/F/U, chuẩn hóa +84 về 0, và đưa NgaySinh không hợp lệ về NULL chứ không bịa ngày.

Tóm tắt

Mô hình hóa di chuyển dữ liệu là kỹ năng then chốt giúp một BA biến cơn ác mộng "chuyển hệ thống" thành một quy trình có kiểm soát. Hãy ghi nhớ những điểm cốt lõi:

Luôn đi qua staging trung gian giữa source và target, không chuyển trực tiếp.
Sản phẩm trung tâm của BA là mapping specification với transformation rules và chiến lược xử lý ngoại lệ rõ ràng.
Thiết kế các bảng phụ trợ: crosswalk để giữ liên kết khóa, error table cho dữ liệu lỗi, reconciliation table để chứng minh thành công.
Ưu tiên pilot và incremental thay vì big bang; định nghĩa tiêu chí đối soát trước khi chạy.
Chất lượng dữ liệu nguồn gần như luôn tệ hơn bạn tưởng — hãy profiling, đừng tin tài liệu.

Khi bạn làm tốt phần mô hình hóa này, đội kỹ thuật có một bản thiết kế rõ ràng để thực thi, còn nghiệp vụ có bằng chứng để yên tâm ký nghiệm thu. Đó chính là giá trị mà một BA dữ liệu mang lại.