Bài 14 – Dữ liệu thời gian và lịch sử biến động của một BĐS nên được lưu thế nào? tiếp tục bộ xương V2 của Hệ thống thông tin BĐS. Mục tiêu không phải học thuộc tên bảng, mà hiểu cách mô hình hóa thế giới BĐS thành dữ liệu có định danh, quan hệ, thời gian, nguồn và trách nhiệm quản trị.
Biên soạn: ThS. Nguyễn Mạnh Hùng
Đơn vị: GV. Khoa QLĐĐ&BĐS – ĐH Nông Lâm TP.HCM
Email: nguyenmanhhung@hcmuaf.edu.vn
Cập nhật 30/09/2026: Bài viết phục vụ học tập và giảng dạy trong series Hệ thống thông tin BĐS V2. Nội dung giữ ranh giới với Tin học BĐS và Phân tích TTBĐS: tập trung vào mô hình dữ liệu, quy trình, kiến trúc, quản trị và tích hợp; không biến bài thành hướng dẫn thao tác SQL/GIS hay mô hình thống kê.
Ranh giới với các series khác: Bài tập trung vào mô hình dữ liệu và governance. Kỹ thuật lập trình, SQL, API và phân tích thống kê được dẫn chiếu nhưng không dạy lại.
1. “Hiện tại” không đủ cho BĐS
Một hệ thống chỉ giữ trạng thái hiện tại trả lời được “bây giờ ai đứng tên?”, nhưng không trả lời “ngày 01/01/2024 ai đứng tên?” hoặc “tại thời điểm ra quyết định hệ thống biết gì?”. BĐS có đăng ký, chuyển nhượng, đính chính, gia hạn và biến động kéo dài nên lịch sử là yêu cầu cốt lõi.
2. Hai trục thời gian
Có thể phân biệt thời gian hiệu lực nghiệp vụ (valid time) với thời gian hệ thống ghi nhận (transaction/system time). Một hợp đồng có hiệu lực từ 01/01 nhưng được nhập ngày 05/01; hoặc một sai sót phát hiện sau này cần sửa dữ liệu cũ. Hai trục giúp mô tả chính xác.
3. Version thay vì overwrite
Ghi đè làm mất bằng chứng. Mô hình versioned record giữ bản cũ, tạo bản mới với thời điểm hiệu lực và lý do thay đổi. Người dùng thông thường thấy bản hiện hành; audit có thể xem chuỗi phiên bản.
| Khái niệm | Trả lời câu hỏi | Ví dụ |
|---|---|---|
| Valid time | Thực tế có hiệu lực khi nào? | Hợp đồng hiệu lực 01/01 |
| System time | Hệ thống ghi nhận khi nào? | Nhập 05/01 |
| Version | Bản nào là bản hiện hành? | v3 thay v2 |
| Event | Vì sao đổi? | TRANSFER/SPLIT |
| Source | Dựa vào đâu? | Hợp đồng/quyết định |
4. Event và state
Một cách mạnh là lưu sự kiện: CREATED, REGISTERED, TRANSFERRED, SPLIT, MERGED, LEASED, RENOVATED… Trạng thái hiện tại được suy từ chuỗi sự kiện hoặc materialize để truy vấn nhanh. Event giúp hiểu “vì sao” trạng thái thay đổi.
5. Correction khác business change
Sửa chính tả tên khách khác với chuyển quyền. Correction có thể sửa thông tin sai nhưng không đại diện sự kiện pháp lý; business change tạo trạng thái mới có hiệu lực. Nếu trộn hai loại, lịch sử trở nên khó giải thích.
6. Bitemporal query trong thực tế
Câu hỏi “tại ngày X tài sản có trạng thái gì theo dữ liệu chúng ta biết tại ngày Y?” rất quan trọng trong kiểm toán và tranh chấp. Không phải hệ thống nào cũng cần triển khai bitemporal đầy đủ, nhưng kiến trúc phải hiểu bài toán trước khi quyết định.
7. Snapshot, history table hay event store?
Snapshot định kỳ đơn giản nhưng có thể bỏ mất thay đổi giữa kỳ. History table dễ truy vấn trạng thái. Event store giàu lịch sử nhưng phức tạp hơn. Có thể kết hợp tùy use case. Không có một kỹ thuật duy nhất phù hợp mọi lớp.
8. Retention và khả năng giải thích
Lưu lịch sử không có nghĩa giữ vô hạn mọi dữ liệu. Cần chính sách retention theo pháp luật, nghiệp vụ và rủi ro. Tuy nhiên với record quyết định/quyền tài sản, khả năng truy vết thường có giá trị lâu dài.
Khung thiết kế nâng cao: từ khái niệm đến hệ thống có thể vận hành
Ở góc dữ liệu doanh nghiệp, mô hình chỉ có giá trị khi chuyển được thành quy tắc vận hành. Mỗi đối tượng phải có định danh, owner, source, trạng thái, thời gian, quyền truy cập và quy tắc thay đổi. Nếu thiếu một trong các lớp này, mô hình ER đẹp vẫn có thể tạo dữ liệu không đáng tin.
| Lớp kiểm soát | Câu hỏi thiết kế | Bằng chứng nghiệm thu |
|---|---|---|
| Identity | Cùng một đối tượng được nhận diện thế nào? | ID/namespace/crosswalk |
| Semantics | Trường này nghĩa chính xác là gì? | Data dictionary/code list |
| Source | Ai/cái gì khẳng định dữ liệu? | Source + provenance |
| Time | Đúng ở thời điểm nào? | Effective/version fields |
| Ownership | Ai chịu trách nhiệm? | Data owner/steward |
| Access | Ai xem/sửa/duyệt? | Role/permission/audit |
| Change | Thay đổi qua quy trình nào? | Workflow/event/version |
Ở mức thiết kế, có thể dùng valid_from/valid_to cho record nghiệp vụ và system_from/system_to cho audit nâng cao. Tránh dùng một cột “thời điểm cập nhật gần nhất” để thay cho lịch sử; trường này chỉ cho biết lần sửa gần nhất, không cho biết trạng thái trước.
Một nguyên tắc quan trọng là không để schema vật lý quyết định nghiệp vụ. Nếu hệ thống hiện tại có một cột nhưng nghiệp vụ thực tế là quan hệ nhiều–nhiều, hãy sửa mô hình thay vì ép nghiệp vụ vào cột. Ngược lại, không cần tạo hàng chục thực thể chỉ để thể hiện sự 'đúng chuẩn' nếu tổ chức không có use case và governance tương ứng.
Tình huống thiết kế và phòng thí nghiệm quyết định
Tình huống giả lập: hợp đồng chuyển nhượng có hiệu lực ngày 10/3, hồ sơ được nhập 15/3, ngày 20/3 phát hiện tên người nhận sai chính tả. Cần trả lời hệ thống đã biết gì vào 12/3, 18/3 và trạng thái pháp lý thực tế là gì. Đây là bài toán hai trục thời gian.
| Bước | Việc phải làm | Câu hỏi phản biện |
|---|---|---|
| 1. Xác định đối tượng | Liệt kê entity/domain | Có đang trộn object với document/process? |
| 2. Xác định quan hệ | Cardinality + role | M:N có thuộc tính riêng không? |
| 3. Gắn thời gian | Effective/version/event | Có tái dựng lịch sử được không? |
| 4. Gắn nguồn | Source/provenance | Ai chứng minh dữ liệu? |
| 5. Gắn governance | Owner/permission | Ai có quyền sửa? |
| 6. Test ngoại lệ | Split/merge/correction | Mô hình có vỡ khi nghiệp vụ khó? |
Sinh viên không cần viết code ở bước này. Yêu cầu là vẽ mô hình, giải thích từng quan hệ và chứng minh mô hình xử lý được ngoại lệ. Nếu một thiết kế chỉ chạy trong ví dụ 'mỗi tài sản một chủ, mỗi khách một hợp đồng' thì chưa đủ cho BĐS thực tế.
Kiểm soát chất lượng dữ liệu và khả năng truy vết
Chất lượng dữ liệu không chỉ là “đủ trường”. Với mô hình BĐS, cần kiểm tra ít nhất tính đầy đủ, hợp lệ, nhất quán, duy nhất, kịp thời và truy vết được nguồn. Một record có đầy đủ thông tin nhưng source không rõ vẫn có rủi ro cao; một record đúng nhưng đã hết hiệu lực cũng không nên dùng cho quyết định hiện tại.
| Chiều chất lượng | Ví dụ lỗi | Kiểm soát |
|---|---|---|
| Completeness | Thiếu ID/source/effective date | Required rule + exception queue |
| Validity | Loại quyền ngoài code list | Reference data validation |
| Consistency | CRM và master khác loại tài sản | Reconciliation |
| Uniqueness | Hai record cùng đối tượng | Matching/duplicate workflow |
| Timeliness | Thông tin quá hạn | Expiry/SLA |
| Traceability | Không biết dữ liệu từ đâu | Provenance/audit |
Hãy luôn thêm exception workflow. Dữ liệu thực tế không bao giờ sạch tuyệt đối; hệ thống trưởng thành không phải hệ thống “không có lỗi” mà là hệ thống phát hiện, phân công, xử lý và học từ lỗi có cấu trúc.
Khung áp dụng thực tế
- Lấy một sự kiện chuyển nhượng giả lập và ghi valid/system time.
- Thiết kế 3 version trước–sau.
- Thử correction sau 10 ngày.
- Viết truy vấn nghiệp vụ cần trả lời ở quá khứ (không cần SQL).
Những sai lầm cần tránh
- Dùng trường thời điểm cập nhật gần nhất thay cho lịch sử.
- Ghi đè bản cũ.
- Trộn correction với legal change.
- Không lưu effective date/source.
Bài tập thực hành
Chọn một hệ thống thật hoặc giả lập. Không bắt đầu bằng giao diện. Hãy viết danh sách đối tượng nghiệp vụ, quan hệ, mã định danh, source, thời gian hiệu lực, người chịu trách nhiệm và các ngoại lệ. Sau đó vẽ mô hình khái niệm và dùng ít nhất hai tình huống khó để phá thử mô hình. Cuối cùng ghi rõ phần nào là dữ liệu chủ, phần nào là giao dịch, phần nào là tài liệu và phần nào là lịch sử.
Câu hỏi tự kiểm tra
- Đối tượng chính của mô hình là gì và có định danh độc lập không?
- Quan hệ nào là 1:N, quan hệ nào thực chất là M:N?
- Mô hình có giữ được source và lịch sử hay chỉ trạng thái hiện tại?
- Ai là Data Owner và ai được quyền sửa?
- Nếu hai hệ thống có ID khác nhau, ta nối chúng bằng cơ chế nào?
- Thiết kế có đứng vững khi xảy ra split, merge, correction hoặc nhiều chủ thể không?
Kiểm thử mô hình bằng các ngoại lệ thường gặp trong BĐS
Một mô hình tốt phải xử lý được ngoại lệ trước khi triển khai. Hãy thử năm nhóm: nhiều chủ thể, nhiều hệ định danh, thay đổi theo thời gian, hồ sơ đến muộn/sửa sai và tách–hợp đối tượng. Nếu phải sửa cấu trúc bảng mỗi khi gặp ngoại lệ, conceptual model chưa đủ tổng quát.
| Ngoại lệ | Câu hỏi test | Dấu hiệu mô hình yếu |
|---|---|---|
| Nhiều chủ thể | Một quyền có 3 bên thì sao? | Chỉ có owner_id |
| Nhiều ID | CRM/GIS/ERP dùng mã khác? | Join bằng tên/địa chỉ |
| Thời gian | Xem trạng thái 2 năm trước? | Chỉ giữ current |
| Correction | Sửa sai có xóa lịch sử? | Overwrite |
| Split/Merge | Đối tượng mới kế thừa gì? | Không có lineage |
Sau mỗi test, không chỉ sửa schema. Hãy hỏi liệu lỗi nằm ở định nghĩa nghiệp vụ, code list, workflow hay governance. Nhiều vấn đề dữ liệu không thể giải quyết chỉ bằng thêm cột.
Decision log cho thiết kế dữ liệu
Mỗi quyết định mô hình quan trọng nên có nhật ký: vấn đề, các phương án, lựa chọn, lý do, tác động, người phê duyệt và ngày xem lại. Ví dụ quyết định chọn một PropertyMasterID nội bộ thay vì dùng mã CRM cần ghi rõ vì sao: CRM ID phụ thuộc ứng dụng và có thể đổi khi thay CRM. Decision log giúp đội ngũ sau này hiểu ý định thiết kế thay vì suy đoán từ schema.
Ghi nhớ trong 30 giây
- Không nên ghi đè trạng thái cũ nếu tổ chức cần chứng minh lịch sử.
- Ngày hiệu lực nghiệp vụ khác ngày dữ liệu được nhập hoặc sửa trong hệ thống.
- Hai trục thời gian giúp xử lý đăng ký muộn, hiệu chỉnh và truy vết quyết định.
- Versioning cần có nguồn, người thay đổi, lý do và mốc hiệu lực.
- Lịch sử tốt là nền tảng cho audit, pháp lý, phân tích chuỗi thời gian và AI đáng tin.
Nguồn tham khảo
- ISO 19152-1:2024 – LADM generic conceptual model, gồm khái niệm versioned object và source.
- ISO 19152-2:2025 – land registration và thông tin quyền/không gian có lịch sử.
- DAMA-DMBOK2 – temporal data, auditability và data governance.
- Thông tư 10/2024/TT-BTNMT – hồ sơ địa chính và đăng ký đất đai, tham khảo bối cảnh Việt Nam.
Bài tiếp theo: “Từ mô hình nghiệp vụ đến mô hình quan hệ: ER, khóa và chuẩn hóa dùng ở mức nào?”.