Bài 45 — Data Integration Patterns — Data Modeling and ERD Mastery

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

Trong 44 bài trước, chúng ta đã dành rất nhiều thời gian để thiết kế một mô hình dữ liệu hoàn hảo cho một hệ thống: entity gọn gàng, khóa chính rõ ràng, chuẩn hóa đến 3NF, đánh index hợp lý. Nhưng thực tế phũ phàng là: trong một doanh nghiệp thật, dữ liệu của bạn không bao giờ sống một mình. Nó nằm rải rác ở hàng chục hệ thống — phần mềm kế toán MISA, hệ thống CRM, cổng thanh toán VNPay, sàn thương mại điện tử Shopee, kho hàng Excel do một bạn nào đó tự làm, và cả cái hệ thống core cũ kỹ viết từ 15 năm trước mà không ai dám đụng vào.

Câu hỏi mà một Business Analyst (BA) về dữ liệu buộc phải trả lời không còn là "mô hình này đẹp chưa" mà là "làm sao để dữ liệu chảy giữa các hệ thống này một cách chính xác, kịp thời và không mâu thuẫn". Đó chính là Data Integration — tích hợp dữ liệu.

Bài này cực kỳ quan trọng vì ranh giới giữa "một mô hình chết trên giấy" và "một hệ thống chạy được trong doanh nghiệp" nằm chính ở khả năng tích hợp. Rất nhiều dự án chuyển đổi số ở Việt Nam thất bại không phải vì thiết kế database sai, mà vì hai hệ thống không nói chuyện được với nhau, hoặc nói chuyện sai. Với vai trò BA, bạn thường là người đầu tiên phát hiện nhu cầu tích hợp, và là người vẽ ra bức tranh dữ liệu chảy như thế nào trước khi lập trình viên bắt tay vào code. Hiểu các integration pattern (mẫu tích hợp) giúp bạn nói đúng ngôn ngữ với kiến trúc sư hệ thống và tránh những quyết định đắt giá.

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

Khi nào cần tích hợp dữ liệu?

Trước khi bàn "làm thế nào", hãy nhận diện "khi nào". Nhu cầu tích hợp thường phát sinh trong bốn tình huống điển hình:

Nhiều hệ thống cùng dùng chung một loại dữ liệu. Ví dụ dữ liệu khách hàng vừa nằm ở CRM, vừa nằm ở hệ thống bán hàng, vừa nằm ở phần mềm chăm sóc khách hàng. Nếu không tích hợp, mỗi nơi một phiên bản, số điện thoại khách ở CRM khác với ở hệ thống giao hàng.
Ứng dụng mới phải làm việc với hệ thống cũ (legacy). Bạn xây một app đặt hàng hiện đại nhưng phải đẩy đơn vào hệ thống ERP đời cũ. App mới không thể ghi thẳng vào database cũ mà thường phải qua một lớp trung gian.
Đồng bộ thời gian thực giữa các vùng/chi nhánh. Một chuỗi bán lẻ có kho ở Hà Nội, TP.HCM, Đà Nẵng cần biết tồn kho thực tế ngay lập tức để bán hàng online không bị "oversell" (bán vượt tồn).
Cần gom dữ liệu để phân tích (ETL). Dữ liệu giao dịch nằm ở hệ thống vận hành (OLTP), nhưng để làm báo cáo, phải trích xuất, biến đổi và nạp vào kho dữ liệu — đây là quy trình ETL mà chúng ta sẽ nói kỹ ở dưới.

Các mẫu tích hợp chính

1. File-based / Batch integration (tích hợp theo tệp, theo lô). Hệ thống A xuất một file (CSV, Excel, XML) theo lịch, hệ thống B đọc file đó và nạp vào. Đây là cách cổ điển nhất, đơn giản, dễ kiểm soát, nhưng có độ trễ — dữ liệu thường chỉ cập nhật theo giờ hoặc theo ngày. Vẫn cực kỳ phổ biến trong ngành ngân hàng và bảo hiểm Việt Nam.

2. Database-level integration (tích hợp ở tầng cơ sở dữ liệu). Hai hệ thống chia sẻ chung một database, hoặc dùng cơ chế replication (nhân bản), hoặc một hệ thống đọc trực tiếp bảng của hệ thống kia. Nhanh nhưng nguy hiểm: nó tạo ra "coupling" chặt — đổi cấu trúc bảng ở một bên là bên kia gãy ngay. Nói chung nên tránh cho hệ thống mới.

3. API-based integration (tích hợp qua API). Hệ thống A gọi API (thường là REST hoặc SOAP) của hệ thống B để lấy hoặc đẩy dữ liệu. Đây là chuẩn hiện đại: mỗi hệ thống che giấu database của mình, chỉ lộ ra hợp đồng dữ liệu (contract) rõ ràng. Phù hợp cho các thao tác đồng bộ, cần phản hồi ngay (ví dụ kiểm tra số dư trước khi chuyển tiền).

4. Event/Message-based integration (tích hợp qua sự kiện/tin nhắn). Thay vì A gọi thẳng B, A phát ra một "sự kiện" (event) như đơn hàng đã tạo lên một hàng đợi tin nhắn (message queue như Kafka, RabbitMQ). Các hệ thống quan tâm sẽ tự lắng nghe và xử lý. Đây là mô hình "loosely coupled" (kết nối lỏng) — A không cần biết ai đang nghe, giúp mở rộng dễ và chịu lỗi tốt. Rất mạnh cho đồng bộ thời gian thực và kiến trúc microservices.

5. ETL / ELT. ETL = Extract (trích xuất) → Transform (biến đổi) → Load (nạp). Bạn lấy dữ liệu từ nhiều nguồn, làm sạch và định dạng lại, rồi nạp vào đích (thường là data warehouse). ELT đảo thứ tự: nạp thô trước rồi biến đổi sau, tận dụng sức mạnh của kho dữ liệu đám mây. Đây là xương sống của mọi hệ thống báo cáo và phân tích.

Ba khái niệm mà BA phải nắm

Data mapping (ánh xạ dữ liệu): trường "makh" ở hệ thống cũ tương ứng với trường "customer_id" ở hệ thống mới; "Nam/Nữ" ánh xạ thành "M/F". Đây là công việc trung tâm của BA khi làm tích hợp.
Sync direction (chiều đồng bộ): một chiều (one-way) hay hai chiều (bi-directional). Hai chiều luôn khó vì phải xử lý xung đột.
System of Record (SoR — hệ thống nguồn chân lý): khi cùng một dữ liệu tồn tại ở nhiều nơi và mâu thuẫn, hệ thống nào là "đúng"? Xác định SoR là quyết định nghiệp vụ, không phải kỹ thuật.

Tình huống thực tế

Ví dụ 1 — Chuỗi bán lẻ đồng bộ tồn kho đa kênh

Một chuỗi mỹ phẩm giả định tên Bloom Cosmetics có 40 cửa hàng và bán song song trên website riêng, Shopee và Lazada. Vấn đề: cùng một thỏi son chỉ còn 3 cái trong kho, nhưng cả website lẫn Shopee đều hiển thị "còn hàng", dẫn đến bán vượt tồn (oversell) khoảng 200 đơn mỗi tháng, mỗi đơn hủy khiến shop bị trừ điểm uy tín trên sàn.

Đội kỹ thuật ban đầu định cho mỗi kênh đọc trực tiếp bảng tồn kho của hệ thống kho — tức database-level integration. BA của dự án phản đối vì mỗi lần sàn gọi vào sẽ khóa bảng, và ba kênh cùng đọc-ghi dễ gây sai số. Thay vào đó, họ chọn event-based: mỗi khi có đơn hàng ở bất kỳ kênh nào, một sự kiện stock_reserved được phát lên hàng đợi; một dịch vụ tồn kho trung tâm lắng nghe, trừ số lượng và phát tiếp sự kiện stock_updated để đẩy con số mới ra tất cả các kênh trong vòng 2–3 giây.

Bài học: khi cần đồng bộ thời gian thực giữa nhiều bên và không muốn các bên phụ thuộc chặt vào nhau, event-based là lựa chọn tự nhiên. BA đã ngăn được một quyết định "chia sẻ database" tưởng nhanh nhưng cực kỳ mong manh.

Ví dụ 2 — Ngân hàng tích hợp app mới với core cũ

Một ngân hàng cỡ vừa (gọi là DongA Digital) muốn ra mắt app cho vay tiêu dùng nhanh. Điểm nghẽn: hệ thống core banking đã chạy 12 năm, chỉ mở giao tiếp qua các file batch cuối ngày và một vài giao dịch SOAP hạn chế.

Giải pháp lai (hybrid): những thao tác cần ngay lập tức — như kiểm tra khách có phải khách hàng hiện hữu, có nợ xấu không — được thực hiện qua API đồng bộ (SOAP) tới core. Còn việc hạch toán giải ngân, do core chỉ chốt sổ cuối ngày, được gom lại và đẩy qua file batch lúc 22h mỗi tối. BA đã phải lập một bảng data mapping chi tiết: mã sản phẩm vay trên app "TD-001" ánh xạ thành mã "0451" trong core, ngày sinh app dùng định dạng YYYY-MM-DD còn core dùng DDMMYYYY.

Kết quả: khách được duyệt trong 5 phút (nhờ API real-time), còn tiền được hạch toán chính xác vào sổ cái sau đợt batch tối. Một tháng đầu phát sinh 30 giao dịch lệch do một trường số tiền bị nhầm đơn vị (đồng vs nghìn đồng) — chính bảng mapping thiếu ghi chú đơn vị tiền tệ.

Bài học: hệ thống legacy hiếm khi cho bạn chọn một pattern duy nhất; kết hợp API cho phần cần nhanh và batch cho phần chốt sổ là thực tế phổ biến. Và data mapping mà bỏ sót đơn vị đo là nguồn lỗi kinh điển.

Ví dụ 3 — Doanh nghiệp gom dữ liệu bán hàng để làm báo cáo (ETL)

Một công ty phân phối F&B tên Saigon Foods bán qua ba hệ thống: POS tại cửa hàng, đơn sỉ trên phần mềm riêng, và đơn online. Ban giám đốc muốn một báo cáo doanh thu hợp nhất mỗi sáng. Ba nguồn dùng ba định dạng khác nhau: POS ghi giờ theo múi giờ máy, hệ thống sỉ ghi ngày không kèm giờ, hệ thống online ghi theo UTC.

Đội dữ liệu dựng một quy trình ETL chạy lúc 3h sáng: Extract dữ liệu ngày hôm trước từ ba nguồn; Transform — quy tất cả về múi giờ Việt Nam (UTC+7), chuẩn hóa mã sản phẩm về một danh mục chung, gộp khách hàng trùng lặp; Load vào một kho dữ liệu để dựng báo cáo. Điểm mấu chốt BA làm rõ: hệ thống nào là System of Record cho danh mục sản phẩm — họ chọn hệ thống sỉ, vì đó là nơi phòng mua hàng cập nhật giá gốc.

Bài học: khi tích hợp để phân tích chứ không phải để vận hành, ETL theo lô ban đêm là đủ và an toàn; không phải cái gì cũng cần real-time. Việc xác định SoR cho từng loại dữ liệu là quyết định BA phải chốt sớm.

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

Khi bạn được giao phân tích một nhu cầu tích hợp, hãy đi theo trình tự sau:

Xác định các hệ thống và dữ liệu liên quan. Liệt kê rõ hệ thống nguồn, hệ thống đích, và thực thể dữ liệu nào cần chảy (khách hàng, đơn hàng, tồn kho…).

Làm rõ yêu cầu về độ trễ (latency). Hỏi nghiệp vụ: cần dữ liệu tức thời (giây), gần thời gian thực (phút), hay theo lô (giờ/ngày)? Đây là yếu tố quyết định pattern nhiều nhất. Đừng chọn real-time chỉ vì nghe "xịn" — nó tốn kém và phức tạp.

Xác định chiều đồng bộ. Một chiều hay hai chiều? Nếu hai chiều, phải hỏi ngay: khi hai bên cùng sửa một bản ghi thì ai thắng?

Chỉ định System of Record cho từng trường dữ liệu. Ghi rõ nguồn chân lý. Đây là nền tảng để giải quyết xung đột sau này.

Lập bảng data mapping. Với mỗi trường: tên trường nguồn → tên trường đích, kiểu dữ liệu, quy tắc biến đổi (định dạng ngày, đơn vị, mã hóa), và cách xử lý giá trị rỗng.

Chọn pattern phù hợp dựa trên độ trễ, mức độ coupling chấp nhận được và năng lực của hệ thống legacy: file/batch, API, hay event.

Thiết kế xử lý lỗi và đối soát (reconciliation). Điều gì xảy ra khi bản tin thất lạc? Có cơ chế chạy lại (retry) không? Có báo cáo đối soát cuối ngày để phát hiện lệch không?

Vẽ sơ đồ luồng dữ liệu (data flow diagram) để mọi bên cùng nhìn: dữ liệu xuất phát từ đâu, đi qua đâu, đến đâu, theo tần suất nào.

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

Chọn database-level cho hệ thống mới. Chia sẻ chung bảng nghe có vẻ nhanh nhưng tạo coupling chặt, đổi schema là gãy dây chuyền. Mẹo: mặc định ưu tiên API hoặc event, chỉ dùng chia sẻ database khi thật sự bắt buộc.

Bỏ quên xử lý xung đột trong đồng bộ hai chiều. Nhiều dự án giả định "sẽ không có ai sửa cùng lúc" — sai lầm. Luôn định nghĩa quy tắc: last-write-wins, hoặc SoR thắng, hoặc đưa cho con người duyệt.

Data mapping thiếu chi tiết. Bỏ sót đơn vị đo, múi giờ, hay cách xử lý NULL là nguyên nhân số một gây lệch dữ liệu — như đơn vị tiền tệ ở ví dụ ngân hàng. Mẹo: mọi trường số phải ghi rõ đơn vị, mọi trường ngày/giờ phải ghi rõ múi giờ.

Không có cơ chế đối soát. Tích hợp nào cũng có lúc rớt bản tin. Không đối soát nghĩa là bạn phát hiện lệch khi khách hàng khiếu nại. Mẹo: luôn có báo cáo so khớp số lượng/tổng tiền giữa nguồn và đích cuối mỗi kỳ.

Chọn real-time khi không cần. Real-time tốn hạ tầng và khó vận hành gấp nhiều lần batch. Mẹo: hỏi thật kỹ nghiệp vụ về độ trễ chấp nhận được trước khi cam kết.

Không xác định System of Record. Khi ba hệ thống cùng có "số điện thoại khách" mà không ai là chân lý, dữ liệu sẽ mãi mâu thuẫn. Mẹo: chốt SoR cho từng thực thể ngay từ đầu.

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

Bối cảnh: Một chuỗi phòng khám tư có ba hệ thống — (A) phần mềm đặt lịch online cho bệnh nhân, (B) hệ thống quản lý bệnh án tại quầy lễ tân, (C) phần mềm kế toán để xuất hóa đơn. Khi bệnh nhân đặt lịch online rồi đến khám, thông tin phải chảy qua cả ba nơi.

Hãy hoàn thành các phần sau:

Với mỗi cặp hệ thống cần trao đổi dữ liệu (A→B, B→C), xác định yêu cầu độ trễ (real-time hay batch) và giải thích lý do dựa trên nghiệp vụ.

Đề xuất một integration pattern cụ thể cho mỗi cặp và nêu lý do tại sao chọn pattern đó thay vì các pattern còn lại.

Chỉ định System of Record cho ba loại dữ liệu: thông tin nhân khẩu bệnh nhân, lịch hẹn, và số tiền hóa đơn.

Lập một bảng data mapping mẫu (ít nhất 5 trường) cho luồng A→B, trong đó có ít nhất một trường cần biến đổi định dạng (ví dụ ngày sinh) và một trường cần ánh xạ giá trị (ví dụ giới tính).

Nêu một tình huống lỗi có thể xảy ra (ví dụ bệnh nhân đặt lịch nhưng thông tin không sang được lễ tân) và đề xuất cơ chế đối soát để phát hiện.

Gợi ý: A→B nên gần real-time vì bệnh nhân có thể đến khám ngay sau khi đặt; B→C có thể chạy batch cuối ngày vì hóa đơn thường xuất theo ca hoặc cuối ngày.

Tóm tắt

Data integration là chiếc cầu nối biến những mô hình dữ liệu riêng lẻ thành một hệ sinh thái thông tin vận hành được trong doanh nghiệp thật. Nhu cầu tích hợp nảy sinh khi nhiều hệ thống dùng chung dữ liệu, khi app mới phải sống chung với hệ thống cũ, khi cần đồng bộ thời gian thực giữa các vùng, và khi cần gom dữ liệu để phân tích qua ETL.

Có năm mẫu tích hợp chính: file/batch (đơn giản, có độ trễ), database-level (nhanh nhưng coupling chặt, nên tránh), API (chuẩn hiện đại cho thao tác đồng bộ), event/message (loosely coupled, mạnh cho real-time và microservices), và ETL/ELT (xương sống của báo cáo). Không có pattern nào "tốt nhất" tuyệt đối — lựa chọn phụ thuộc vào độ trễ nghiệp vụ yêu cầu, mức coupling chấp nhận được và giới hạn của hệ thống legacy; thực tế thường là kết hợp lai.

Với vai trò BA, ba việc bạn không được bỏ qua là: xác định System of Record cho từng loại dữ liệu, lập data mapping đầy đủ đến từng đơn vị và múi giờ, và thiết kế cơ chế đối soát để lệch dữ liệu không âm thầm tích tụ. Nắm vững những điều này, bạn sẽ là người vẽ đúng bức tranh luồng dữ liệu trước khi một dòng code được viết ra.