Từ lúc bấm Lưu đến khi dữ liệu có hiệu lực
Một lần bấm Lưu chưa chắc làm dữ liệu có hiệu lực. Nội dung cập nhật còn cần được kiểm tra, phê duyệt, công bố và lưu lại lịch sử.
Một người mở hồ sơ tài sản, sửa trạng thái từ “đang hoạt động” thành “tạm ngừng”, đính kèm biên bản kiểm tra rồi bấm Lưu. Hệ thống báo thành công.
Thông báo ấy mới trả lời được một việc: hệ thống đã nhận thao tác. Nó chưa nói thông tin cũ còn hiệu lực hay không, thay đổi đã qua kiểm tra chưa, người khác đã được phép dùng giá trị mới chưa, hoặc vài ngày sau có thể lần lại vì sao nó được sửa hay không.
Điều khó của một hệ thống dữ liệu dùng chung thường bắt đầu ở đây. Nút Lưu rất nhỏ, nhưng phía sau nó là một lời hứa khá lớn: mỗi thay đổi phải đi đến đúng trạng thái, đúng người có trách nhiệm và đúng thời điểm có hiệu lực.
Bài viết này không mô tả một quy trình bắt buộc cho mọi WebGIS. Chúng tôi chỉ đi theo một thay đổi bình thường để nhìn rõ những điều cần giữ, dù hệ thống đơn giản hay phức tạp.
Lưu thành công chưa chắc thông tin mới đã có hiệu lực
Trong một danh mục do một người quản lý, người có quyền sửa có thể đồng thời là người chịu trách nhiệm về dữ liệu. Khi đó, bấm Lưu và đưa thay đổi vào sử dụng ngay là hợp lý.
Nhưng nếu dữ liệu phục vụ nhiều bộ phận, liên quan đến tài sản ngoài thực địa hoặc được dùng để ra quyết định, thao tác Lưu thường chỉ ghi nhận nội dung cập nhật. Nội dung đó có thể được kiểm tra tự động, gửi cho người có trách nhiệm xem xét hoặc có hiệu lực ngay nếu người sửa đã được giao đủ thẩm quyền.
Không cần làm quy trình dài chỉ để trông có vẻ chặt chẽ. Điều cần tránh là dùng cùng một chữ “đã lưu” cho nhiều ý nghĩa khác nhau:
- đã giữ bản nháp để người sửa làm tiếp;
- đã gửi cho người khác kiểm tra;
- đã được phê duyệt và trở thành thông tin hiện hành;
- đã được đồng bộ đến những nơi đang sử dụng dữ liệu.
Nếu giao diện không phân biệt được những ý nghĩa này, người dùng phải tự đoán. Khi có sai lệch, mỗi người lại hiểu chữ “đã lưu” theo một cách.
Những thông tin cần đi cùng một thay đổi
Giá trị mới chỉ là một phần nhỏ. Với thay đổi trạng thái tài sản ở trên, hệ thống còn cần biết ít nhất năm điều.
Đối tượng nào đã được sửa. Mã định danh cần ổn định để lần thay đổi hôm nay vẫn nối được với lịch sử, hồ sơ và các lần kiểm tra trước đó của cùng một đối tượng.
Giá trị nào bị thay thế. Chỉ lưu kết quả cuối cùng sẽ làm mất bối cảnh của dữ liệu. Khi biết giá trị trước là “đang hoạt động” và giá trị sau là “tạm ngừng”, người đọc mới hiểu nội dung đã thay đổi.
Ai thay đổi, vào lúc nào. Đây không chỉ là nhật ký kỹ thuật. Nó giúp tìm đúng người để làm rõ khi thông tin thiếu căn cứ, và giúp phân biệt thao tác của con người với một lần nhập hoặc xử lý tự động.
Vì sao thay đổi. Một câu giải thích ngắn, biên bản kiểm tra, phiếu công việc hoặc nguồn dữ liệu liên quan thường có giá trị hơn nhiều trường metadata được điền cho đủ. Không phải trường hợp nào cũng cần tệp đính kèm, nhưng thay đổi quan trọng không nên đứng một mình mà không có căn cứ.
Thay đổi dựa trên phiên bản nào. Nếu người dùng bắt đầu sửa từ một hồ sơ cũ, hệ thống cần nhận ra trước khi ghi đè lên phần việc mới hơn của người khác.
Có thêm một cặp thời điểm dễ bị gộp nhầm: lúc thông tin được ghi vào hệ thống và lúc thông tin có hiệu lực ngoài thực tế. Một tài sản có thể ngừng hoạt động từ ngày 17 nhưng đến ngày 20 biên bản mới được nhập. Cả hai mốc đều đúng, nhưng trả lời hai câu hỏi khác nhau. Không nhất thiết hệ thống nào cũng phải dùng mô hình dữ liệu thời gian phức tạp; ít nhất, tên trường và cách hiển thị không nên làm người dùng hiểu hai mốc là một.
Cách nhìn này gần với tinh thần của W3C PROV-O: giữ được quan hệ giữa thông tin được tạo ra, hoạt động đã tạo ra nó và người hoặc hệ thống chịu trách nhiệm. Không cần triển khai toàn bộ tiêu chuẩn mới học được điều quan trọng ấy.
Phê duyệt là quyết định về hiệu lực của thông tin
Kiểm tra tự động có thể phát hiện trường bắt buộc bị bỏ trống, giá trị sai kiểu, hình học không hợp lệ hoặc một quan hệ không tồn tại. Nó không tự biết biên bản đính kèm có đủ căn cứ để thay đổi trạng thái tài sản hay không.
Ngược lại, người rà soát có thể hiểu nghiệp vụ nhưng không nên phải dò bằng mắt những lỗi mà hệ thống kiểm tra được. Hai việc này bổ sung cho nhau:
- hệ thống kiểm tra những quy tắc có thể diễn đạt rõ;
- người có trách nhiệm đánh giá căn cứ, phạm vi và hệ quả của thay đổi.
Khi nội dung cập nhật được phê duyệt, hệ thống cần ghi được: ai phê duyệt, phạm vi nào được duyệt, thời điểm thực hiện và thời điểm thông tin mới bắt đầu có hiệu lực. Với thay đổi nhỏ, việc lưu và phê duyệt có thể diễn ra trong một thao tác nếu quy định cho phép. Với thay đổi nhạy cảm, người phê duyệt có thể phải độc lập với người chỉnh sửa.
Phê duyệt không có nghĩa dữ liệu sẽ đúng mãi mãi. Nó xác nhận rằng, trong phạm vi trách nhiệm và căn cứ hiện có, đây là phiên bản được phép sử dụng. Khi có kết quả kiểm tra mới, hệ thống vẫn phải cho phép cập nhật mà không làm mất lịch sử của phiên bản trước.
Thời điểm thông tin mới bắt đầu được sử dụng
Sau khi được phê duyệt, thông tin mới bắt đầu được sử dụng: người khác mở hồ sơ, tìm kiếm, xem bản đồ, nhận dữ liệu chia sẻ hoặc lập báo cáo. Tùy kiến trúc, một số nơi đọc trực tiếp từ dữ liệu hiện hành; một số nơi dùng bản sao, chỉ mục tìm kiếm, bộ nhớ đệm hoặc sản phẩm được tạo theo đợt.
Vì vậy, “đã được phê duyệt” và “đã xuất hiện ở mọi nơi” không phải lúc nào cũng cùng một thời điểm.
Độ trễ không tự nó là lỗi. Một báo cáo được chốt cuối ngày hay một gói dữ liệu được phát hành theo tuần có thể là lựa chọn đúng. Vấn đề chỉ xuất hiện khi hệ thống tạo cảm giác rằng mọi nơi đã dùng thông tin mới trong khi một phần vẫn đang đọc phiên bản cũ.
Người dùng không cần biết phía sau dùng bộ nhớ đệm, bản sao hay hàng đợi xử lý gì. Họ cần một câu trả lời dễ hiểu hơn:
- thông tin hiện hành là phiên bản nào;
- nơi mình đang xem được cập nhật đến thời điểm nào;
- thay đổi đang chờ xử lý hay đã gặp lỗi;
- nếu có độ trễ, khi nào dự kiến hoàn tất.
Trong một WebGIS có bản đồ 2D, cảnh 3D, API hoặc báo cáo, đây chỉ là những nơi có thể sử dụng thông tin. Chúng không phải bốn chặng bắt buộc của mọi thay đổi. Câu hỏi chung vẫn là: nơi đang sử dụng dữ liệu có nói thật về phiên bản và độ mới của nó hay không?
Một mã phiên bản, thời điểm cập nhật hoặc trạng thái công bố đôi khi đã đủ. Phần kỹ thuật có thể phức tạp, nhưng thông điệp dành cho người dùng nên ngắn và nhất quán.
Xử lý khi hai người cùng sửa một hồ sơ
Giả sử hai người cùng mở một hồ sơ. Người thứ nhất cập nhật vị trí kiểm tra gần nhất rồi lưu. Người thứ hai, vẫn đang nhìn phiên bản cũ, sửa trạng thái và lưu sau đó.
Nếu hệ thống nhận cả hai giá trị cuối cùng mà âm thầm xóa phần thay đổi trước, người dùng chỉ thấy “lưu thành công” nhưng dữ liệu đã mất. Một cách xử lý tốt hơn là nhận ra hồ sơ đã thay đổi trong lúc người thứ hai đang làm và cho họ biết phần nào khác đi.
Không phải xung đột nào cũng cần từ chối toàn bộ. Hai người sửa hai trường độc lập có thể được ghép nếu quy tắc nghiệp vụ cho phép. Hai người cùng sửa một trạng thái thì cần chọn lại hoặc yêu cầu xem xét. Điều quan trọng là hệ thống không tự quyết trong im lặng.
Ở lớp kỹ thuật, điều kiện cập nhật bằng ETag và If-Match trong RFC 9110, kết hợp với giao dịch và cơ chế kiểm soát đồng thời của cơ sở dữ liệu, là một cách phổ biến để tránh ghi đè mất thay đổi. Tài liệu PostgreSQL về kiểm soát đồng thời là một ví dụ triển khai, không phải yêu cầu mọi WebGIS phải dùng PostgreSQL.
Từ phía người dùng, yêu cầu đơn giản hơn nhiều: nếu dữ liệu đã đổi kể từ lúc họ mở hồ sơ, hãy nói rõ và giúp họ quyết định trên phiên bản mới nhất.
Sửa sai mà không xóa lịch sử
Một bản ghi đã có hiệu lực vẫn có thể sai. Khi phát hiện sai, phản xạ tự nhiên là sửa lại giá trị cho đúng. Nhưng nếu sửa trực tiếp và xóa dấu vết cũ, hệ thống sẽ không còn giải thích được các quyết định hoặc báo cáo đã tạo trong khoảng thời gian trước đó.
Cách an toàn hơn là tạo một thay đổi mới thay thế phiên bản cũ, ghi rõ lý do sửa và thời điểm phiên bản mới bắt đầu có hiệu lực. Nếu cần quay lại giá trị trước, việc “quay lại” cũng nên được ghi như một thay đổi có trách nhiệm, thay vì làm lịch sử trông như chưa từng có sai sót.
Điều này không có nghĩa phải giữ mọi bản nháp vô thời hạn. Chính sách lưu trữ có thể khác nhau theo loại dữ liệu và trách nhiệm pháp lý. Nhưng những phiên bản từng được dùng để ra quyết định cần được quản lý thận trọng hơn dữ liệu tạm trong quá trình biên tập.
Quyền không chỉ là quyền bấm nút
Trong cùng một hệ thống, một người có thể được quyền đề nghị thay đổi nhưng không có quyền phê duyệt; được xem trạng thái chung nhưng không được đọc hồ sơ nhạy cảm; hoặc chỉ được phê duyệt dữ liệu trong khu vực mình phụ trách.
Vì vậy, ẩn nút trên giao diện chưa phải là kiểm soát quyền. Quyền cần được kiểm tra tại nơi hệ thống thực sự đọc hoặc ghi dữ liệu. Những bản sao đã tạo, tệp đã xuất và bộ nhớ đệm cũng cần được tính đến khi quyền thay đổi.
Vì vậy, hệ thống phải biết mỗi người có quyền chỉnh sửa, gửi duyệt, phê duyệt hoặc công bố dữ liệu trong phạm vi nào.
Sáu câu hỏi để rà một luồng cập nhật
Trước khi bàn đến công nghệ, có thể thử đi hết một thay đổi bằng sáu câu hỏi:
- Thay đổi điều gì? Có nhìn được giá trị trước và sau trên đúng đối tượng không?
- Dựa trên căn cứ nào? Có nguồn, lý do hoặc người chịu trách nhiệm để làm rõ không?
- Bắt đầu từ phiên bản nào? Hệ thống có nhận ra dữ liệu đã đổi trong lúc người dùng đang làm không?
- Đang ở trạng thái nào? Là bản nháp, đang chờ xem xét hay đã được phép dùng?
- Có hiệu lực từ khi nào? Thời điểm ngoài thực tế có bị lẫn với thời điểm nhập hệ thống không?
- Đã được dùng ở đâu? Những nơi chưa cập nhật có được báo rõ thay vì âm thầm hiển thị dữ liệu cũ không?
Nếu sáu câu này chưa có câu trả lời, thêm chức năng hoặc một công nghệ đồng bộ nhanh hơn cũng chưa giải quyết được phần cốt lõi. Ngược lại, khi ý nghĩa của thay đổi đã rõ, lựa chọn kỹ thuật thường dễ đánh giá hơn: nó có giữ được định danh, phiên bản, trách nhiệm và trạng thái mà công việc cần hay không.
Bài Chuẩn bị đầu bài WebGIS giúp đặt các câu hỏi này vào phạm vi và người dùng cụ thể. Bài API dữ liệu không gian đi sâu hơn vào thỏa thuận trao đổi dữ liệu. Bài WebGIS nên giúp người dùng hoàn thành một việc cụ thể bàn về cách hoàn tất một tác vụ thay vì dừng ở việc hiển thị chức năng.
Minh bạch về trạng thái quan trọng hơn cảm giác tức thời
Một WebGIS đáng tin cần thể hiện đúng trạng thái của nội dung cập nhật: đã được ghi nhận hay chưa, ai đang chịu trách nhiệm, phiên bản nào có hiệu lực và nơi nào còn sử dụng thông tin cũ.
Khi làm được điều đó, nút Lưu trở về đúng kích thước của nó. Người dùng không phải hiểu kiến trúc phía sau, cũng không phải đoán xem thông báo thành công có nghĩa gì. Họ chỉ cần biết thay đổi mình vừa thực hiện đang ở đâu và điều gì sẽ xảy ra tiếp theo.
Thuận Gió tiếp cận việc cập nhật dữ liệu trong WebGIS từ trách nhiệm, trạng thái và nhu cầu của người dùng, sau đó mới lựa chọn cơ chế kỹ thuật phù hợp.
Tài liệu tham khảo
- W3C PROV-O: mô hình quan hệ giữa thông tin, hoạt động tạo ra thông tin và chủ thể chịu trách nhiệm.
- RFC 9110 — HTTP Semantics: điều kiện cho yêu cầu cập nhật tài nguyên, gồm
ETagvàIf-Match. - PostgreSQL — Concurrency Control: một mô hình triển khai giao dịch và truy cập đồng thời ở lớp cơ sở dữ liệu.