Cách kiểm tra tính đầy đủ của dữ liệu

Điểm quan trọng là “đầy đủ” không đồng nghĩa với “mọi trường đều có dữ liệu”. Trường tùy chọn hoặc không áp dụng hợp lệ không được tính là thiếu. Vì vậy, kiểm tra tính đầy đủ dữ liệu phải kết hợp ba lớp: xác định đúng tập dữ liệu kỳ vọng, kiểm tra sự hiện diện theo ngữ cảnh và đo tỷ lệ đầy đủ trên đúng mẫu số.

Xác định dữ liệu nào bắt buộc phải có trước khi kiểm tra

Muốn biết một bản ghi có thiếu dữ liệu hay không, trước hết phải biết bản ghi đó đáng lẽ phải có những dữ liệu nào. Đây là bước thường bị bỏ qua khi người triển khai bắt đầu bằng việc tìm NULL hoặc ô trống. Nếu chưa định nghĩa tập dữ liệu kỳ vọng, hệ thống không thể phân biệt giữa một trường thực sự bị thiếu và một trường vốn không bắt buộc.

Có thể bắt đầu bằng một ma trận yêu cầu cho từng trường, tối thiểu gồm: tên trường, trạng thái bắt buộc hay tùy chọn, điều kiện khiến trường trở thành bắt buộc và mức độ quan trọng nếu thiếu. Ví dụ, “mã số thuế” có thể bắt buộc với khách hàng là doanh nghiệp nhưng không bắt buộc với cá nhân. Khi đó, yêu cầu completeness không nằm ở việc lấp đầy mọi ô mà ở việc có đủ các giá trị được yêu cầu trong đúng bối cảnh.

Các khung chất lượng dữ liệu như ISO/IEC 25012 cung cấp nền tảng khái niệm cho đặc tính completeness; ISO 8000 và DAMA-DMBOK có thể được dùng làm tham chiếu về quản lý chất lượng dữ liệu. Tuy nhiên, tiêu chuẩn hay khung thực hành không thể thay doanh nghiệp quyết định trường nào là bắt buộc. Quyết định đó phải được ánh xạ thành schema, đặc tả trường hoặc quy tắc kiểm tra cụ thể của hệ thống thu thập.

Ranh giới cần giữ rõ là completeness chỉ trả lời câu hỏi “dữ liệu cần có đã hiện diện chưa”. Một số điện thoại được nhập đủ ký tự nhưng sai vẫn có thể được xem là đầy đủ về mặt hiện diện; việc số đó có chính xác hay không thuộc một kiểm tra khác. Tách hai vấn đề này giúp quy tắc completeness không bị phình thành kiểm tra chất lượng dữ liệu tổng quát.

Kiểm tra trường bắt buộc ngay tại điểm thu thập

Sau khi biết trường nào phải có, kiểm tra nên chạy tại chính điểm dữ liệu đi vào hệ thống: biểu mẫu, ứng dụng, API hoặc luồng nhập dữ liệu. Cơ chế cơ bản là lấy bản ghi đang được gửi, đối chiếu với bộ quy tắc yêu cầu và xác định trường bắt buộc nào chưa có giá trị hợp lệ về mặt hiện diện trước khi chấp nhận bản ghi.

Kiểm tra không nên chỉ dừng ở NOT NULL. Một trường có thể khác NULL nhưng vẫn không chứa dữ liệu hữu ích cho mục đích completeness, chẳng hạn chuỗi rỗng, chỉ có khoảng trắng hoặc một placeholder như “-” được dùng để lách yêu cầu nhập. Vì vậy, quy tắc thường phải chuẩn hóa giá trị trước khi kiểm tra: cắt khoảng trắng, thống nhất cách biểu diễn giá trị thiếu và chỉ sau đó mới đánh giá trường có “present” hay không.

Nếu giao diện người dùng có kiểm tra bắt buộc, vẫn nên lặp lại quy tắc ở ranh giới tin cậy như máy chủ hoặc API. Lý do là dữ liệu có thể đi vào từ kênh khác, script, tích hợp hoặc phiên bản giao diện chưa áp dụng đầy đủ kiểm tra. Kiểm tra ở phía giao diện giúp phản hồi nhanh cho người nhập; kiểm tra ở phía tiếp nhận giúp bảo vệ tính đầy đủ của dữ liệu được hệ thống thực sự chấp nhận.

Một quy trình tối thiểu có thể vận hành theo thứ tự:

·         Xác định bộ quy tắc áp dụng cho bản ghi hiện tại

·         Chuẩn hóa các biểu diễn giá trị thiếu

·         Kiểm tra từng trường bắt buộc

·         Trả về lỗi hoặc cảnh báo tại đúng trường bị thiếu

·         Chỉ chấp nhận bản ghi khi các điều kiện bắt buộc đã được thỏa mãn hoặc có ngoại lệ hợp lệ được ghi nhận

Cơ chế này biến completeness từ một báo cáo phát hiện lỗi sau sự kiện thành một validation gate ngay trong quá trình thu thập. Giới hạn của nó là quy tắc phải đúng và phải được áp dụng trên mọi đường vào dữ liệu; một rule sai hoặc một kênh bỏ qua rule vẫn có thể tạo ra dữ liệu thiếu.

Xử lý trường bắt buộc theo điều kiện và giá trị không áp dụng

Nhiều trường không phải lúc nào cũng bắt buộc. Nếu bỏ qua yếu tố điều kiện, hệ thống sẽ tạo ra hai loại lỗi đối nghịch: báo thiếu sai cho trường không áp dụng, hoặc bỏ sót trường đáng lẽ phải có khi điều kiện đã phát sinh.

Cách xử lý đúng là đánh giá điều kiện trước, rồi mới đánh giá sự hiện diện. Với ví dụ mã số thuế, hệ thống trước hết xác định loại khách hàng. Nếu loại = doanh nghiệp, mã số thuế đi vào tập giá trị kỳ vọng và thiếu giá trị sẽ là lỗi completeness. Nếu loại = cá nhân và quy trình không yêu cầu mã số thuế, trường đó không đi vào mẫu số của phép đo completeness.

Giá trị “không áp dụng” cũng nên được biểu diễn có chủ đích thay vì để trống mơ hồ. Một trạng thái N/A hợp lệ hoặc mã lý do ngoại lệ giúp phân biệt ba tình huống khác nhau: dữ liệu bị quên, dữ liệu chưa biết và dữ liệu thực sự không áp dụng. Nếu cả ba đều được lưu như một ô trống, hệ thống không thể tính completeness chính xác và người vận hành cũng không biết hành động tiếp theo là gì.

Tuy vậy, N/A không nên trở thành lối thoát để vượt qua trường bắt buộc. Chỉ cho phép trạng thái không áp dụng khi có điều kiện nghiệp vụ xác định trước. Với trường bắt buộc tuyệt đối, không có điều kiện loại trừ, việc gắn N/A chỉ che giấu thiếu dữ liệu thay vì giải quyết nó.

Đo tỷ lệ đầy đủ dữ liệu bằng mẫu số đúng

Completeness nên được lượng hóa để có thể theo dõi và so sánh. Công thức hữu ích nhất ở cấp tổng quát là:

Tỷ lệ đầy đủ (%) = Số giá trị được kỳ vọng và thực tế đã có / Tổng số giá trị thực sự được kỳ vọng × 100

Điểm khó nằm ở mẫu số. Nếu mẫu số bao gồm cả các trường tùy chọn hoặc trường không áp dụng cho bản ghi, tỷ lệ sẽ bị kéo xuống một cách giả tạo. Ngược lại, nếu một trường có điều kiện đáng lẽ phải được yêu cầu nhưng bị loại khỏi mẫu số, chỉ số sẽ cao hơn thực tế. Vì vậy, mẫu số phải được dựng sau khi các quy tắc điều kiện đã được đánh giá.

Có thể tính ở hai cấp. Ở cấp trường, tỷ lệ đầy đủ của một trường bằng số bản ghi có giá trị trên số bản ghi mà trường đó được kỳ vọng phải có. Ở cấp bản ghi, tỷ lệ bằng số trường bắt buộc đã có giá trị trên số trường được kỳ vọng ở bản ghi đó. Hai góc nhìn trả lời hai câu hỏi khác nhau: trường nào đang bị thiếu thường xuyên và bản ghi nào chưa đủ để sử dụng.

Với một trường được xác định là bắt buộc tuyệt đối và quan trọng, không có ngoại lệ hợp lệ, mục tiêu chấp nhận tại điểm thu thập nên là 100%: bản ghi thiếu trường đó không được coi là đạt điều kiện hoàn tất. Con số 100% ở đây là mục tiêu kiểm soát do chính trạng thái “bắt buộc” tạo ra, không phải benchmark áp cho mọi trường. Với trường tùy chọn, trường có ngoại lệ hoặc dữ liệu thu thập theo giai đoạn, ngưỡng phù hợp phải do quy trình nghiệp vụ xác định.

Không nên chỉ nhìn một tỷ lệ toàn bộ. Một tập dữ liệu có thể đạt 99% completeness nhưng vẫn thiếu 10% ở một trường quan trọng nếu nhiều trường ít quan trọng khác gần như luôn đầy đủ. Vì thế, dashboard nên tách ít nhất tỷ lệ toàn bộ, tỷ lệ của trường trọng yếu và tỷ lệ theo từng trường có vấn đề. Cách phân tách này ngăn một con số trung bình đẹp che mất lỗ hổng có tác động lớn.

Chọn khi nào chặn, cảnh báo hoặc cho phép ngoại lệ

Không phải mọi trường thiếu đều cần cùng một phản ứng. Nếu chặn tất cả, quy trình thu thập có thể trở nên quá cứng và người nhập dễ chuyển sang điền placeholder để vượt kiểm tra. Nếu chỉ cảnh báo mọi trường, dữ liệu quan trọng vẫn có thể lọt qua. Do đó, mức cưỡng chế nên bám vào mức độ bắt buộc và hậu quả của việc thiếu trường.

Một cách phân tầng thực dụng là:

·         Trường bắt buộc và thiết yếu cho bước xử lý tiếp theo: chặn hoàn tất hoặc chặn gửi

·         Trường quan trọng nhưng có thể bổ sung hợp lệ sau: cảnh báo, đánh dấu bản ghi chưa hoàn thiện và đưa vào hàng chờ bổ sung

·         Trường có ngoại lệ nghiệp vụ hợp lệ: cho phép tiếp tục khi người dùng chọn đúng mã lý do hoặc trạng thái ngoại lệ

·         Trường tùy chọn: không coi là lỗi completeness chỉ vì để trống

Mỗi ngoại lệ nên để lại dấu vết: trường nào được miễn, lý do gì, khi nào phát sinh và ai hoặc quy tắc nào cho phép. Điều này giúp phân biệt “thiếu nhưng được phép” với “thiếu do kiểm soát thất bại”. Nếu không có dấu vết, tỷ lệ completeness có thể trông hợp lệ trong khi quy trình đang lạm dụng ngoại lệ.

Quy tắc chặn cũng cần tránh tạo động lực nhập dữ liệu giả. Nếu một trường chưa thể biết tại thời điểm thu thập nhưng hệ thống vẫn bắt điền bằng mọi giá, người dùng có thể nhập “N/A”, “0000” hoặc giá trị ước đoán. Khi đó, hệ thống đạt completeness về mặt hình thức nhưng mất khả năng nhận biết dữ liệu thực sự chưa có. Giải pháp là mô hình hóa đúng trạng thái “chưa có”, “không áp dụng” và “bắt buộc ngay”, thay vì ép mọi tình huống vào một quy tắc duy nhất.

Theo dõi thiếu dữ liệu theo trường, nguồn và thời điểm

Kiểm tra từng bản ghi là cần thiết nhưng chưa đủ để đánh giá sức khỏe của toàn bộ quá trình thu thập. Một rule có thể hoạt động đúng ở kênh web nhưng bị bỏ qua ở API; một trường có thể bắt đầu thiếu nhiều hơn sau khi biểu mẫu được sửa; hoặc người nhập có thể liên tục chọn một ngoại lệ để vượt qua bước bắt buộc. Những vấn đề này chỉ rõ khi dữ liệu thiếu được tổng hợp thành xu hướng.

Nên ghi log kết quả validation và theo dõi completeness ít nhất theo ba chiều: trường, nguồn/kênh và thời điểm. Ví dụ, nếu một trường có tỷ lệ đầy đủ giảm mạnh chỉ ở dữ liệu đi từ một API tích hợp, nguyên nhân nhiều khả năng nằm ở mapping hoặc rule của nguồn đó hơn là ở toàn bộ hệ thống. Nếu tỷ lệ giảm sau một lần thay đổi form, mốc thời gian giúp khoanh vùng nhanh phiên bản gây lỗi.

Các cảnh báo nên ưu tiên trường trọng yếu và các thay đổi bất thường thay vì chỉ theo dõi một ngưỡng toàn cục. Khi phát hiện mẫu thiếu có hệ thống, hành động hiệu quả nhất thường là sửa ngay tại nguồn: điều chỉnh form, schema, API mapping, logic điều kiện hoặc hướng dẫn người thu thập. Đây là điểm khác biệt giữa việc “đo completeness” và “kiểm soát completeness”: phép đo chỉ cho biết lỗi tồn tại, còn vòng phản hồi giúp ngăn lỗi tiếp tục được tạo ra.

Giám sát không thay thế validation tại điểm thu thập. Hai lớp bổ sung cho nhau: validation giảm khả năng chấp nhận bản ghi thiếu ngay từ đầu, còn monitoring phát hiện các lỗ hổng trong chính hệ thống validation và các mẫu lỗi lặp lại mà một bản ghi riêng lẻ khó thể hiện.

Để kiểm tra tính đầy đủ của dữ liệu trong quá trình thu thập, hãy bắt đầu từ tập dữ liệu được kỳ vọng thay vì từ danh sách ô trống. Xác định rõ trường bắt buộc, tùy chọn và bắt buộc theo điều kiện; kiểm tra sự hiện diện ở điểm nhập; phân biệt thiếu với không áp dụng; sau đó đo completeness bằng mẫu số chỉ gồm những giá trị thực sự phải có.

Với trường bắt buộc tuyệt đối, validation có thể đặt mục tiêu chấp nhận 100% ngay tại đầu vào; với các trường còn lại, cần ngưỡng và cơ chế ngoại lệ phù hợp với quy trình. Cuối cùng, theo dõi tỷ lệ thiếu theo trường, nguồn và thời điểm để phát hiện lỗi có hệ thống và sửa ở nơi dữ liệu được tạo ra. Khi ba lớp quy tắc kỳ vọng – kiểm tra tại nguồn – giám sát định lượng hoạt động cùng nhau, nguy cơ thiếu trường được phát hiện sớm thay vì trở thành vấn đề ở các bước xử lý sau.