Bài 11 – Chủ thể – quyền – hạn chế – trách nhiệm nên được mô hình hóa ra sao? 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. Vì sao một cột “chủ sở hữu” là chưa đủ?
Một mô hình đơn giản thường đặt trực tiếp owner_name hoặc owner_id trong bảng tài sản. Cách này chỉ hoạt động khi mỗi tài sản có đúng một chủ thể và chỉ có một loại quyền. Thực tế quản lý đất đai có đồng sở hữu, quyền sử dụng, quyền thuê, thế chấp, hạn chế, nghĩa vụ và nhiều lớp không gian khác nhau. Vì vậy cần tách chủ thể khỏi quan hệ pháp lý và khỏi đơn vị không gian.
2. Chủ thể (Party) là ai?
Chủ thể có thể là cá nhân, hộ gia đình, tổ chức, cơ quan, doanh nghiệp hoặc nhóm chủ thể theo cấu trúc pháp luật áp dụng. Trong mô hình dữ liệu, chủ thể cần định danh riêng, có tên, loại, trạng thái và hồ sơ nguồn. Không nên lặp họ tên/CCCD vào mọi bảng quyền vì thay đổi một thông tin sẽ tạo nhiều bản sao mâu thuẫn.
3. Quyền – hạn chế – trách nhiệm (RRR) là quan hệ, không phải thuộc tính tĩnh
LADM dùng nhóm khái niệm Rights, Restrictions and Responsibilities – quyền, hạn chế và trách nhiệm – để biểu diễn mối quan hệ giữa chủ thể và đối tượng quản lý. Một quyền phải trả lời: ai có quyền, quyền gì, trên đơn vị nào, tỷ lệ/phạm vi nào, từ khi nào, đến khi nào và dựa trên nguồn nào. Hạn chế và trách nhiệm cũng cần cấu trúc tương tự.
| Thành phần | Câu hỏi dữ liệu | Ví dụ |
|---|---|---|
| Party | Ai? | Cá nhân, tổ chức, nhóm |
| RRR | Có quan hệ pháp lý gì? | Quyền sử dụng, hạn chế, trách nhiệm |
| BAUnit | Quan hệ hành chính được nhóm thế nào? | Đơn vị hành chính cơ bản |
| Spatial Unit | Áp trên không gian nào? | Thửa, căn 3D, hành lang |
| Source | Bằng chứng nào? | Hợp đồng, quyết định, GCN |
4. BAUnit giúp gom quan hệ hành chính
Đơn vị hành chính cơ bản (Basic Administrative Unit – BAUnit) là khái niệm quan trọng để nhóm các quyền, hạn chế và trách nhiệm có cùng cấu trúc quản lý. Đây không nhất thiết trùng hoàn toàn với một thửa đất vật lý. Một quyền có thể bao phủ nhiều đơn vị không gian hoặc một đơn vị không gian có thể chịu nhiều quan hệ pháp lý.
5. Đơn vị không gian không chỉ là polygon thửa đất
Spatial Unit – đơn vị không gian – có thể là thửa đất 2D, không gian pháp lý 3D của căn hộ, phần dưới mặt đất, hành lang kỹ thuật hoặc nhóm đơn vị. Điều này giúp mô hình pháp lý không bị giới hạn bởi bản đồ thửa truyền thống và mở đường cho quản lý 3D.
6. Quan hệ nhiều–nhiều và tỷ lệ quyền
Hai vợ chồng có thể cùng có quyền trên một tài sản; một doanh nghiệp có quyền thuê nhiều không gian; một hạn chế quy hoạch có thể áp lên nhiều thửa. Vì vậy mô hình thường cần bảng/đối tượng liên kết để biểu diễn quan hệ nhiều–nhiều, kèm tỷ lệ, thứ tự ưu tiên, phạm vi và thời hạn.
7. Nguồn và bằng chứng phải là một phần của mô hình
Quyền không nên tồn tại trong hệ thống mà không truy được nguồn tạo lập: quyết định, hợp đồng, giấy chứng nhận, hồ sơ đăng ký hoặc văn bản khác. Mô hình dữ liệu cần liên kết record với source để người dùng biết “vì sao hệ thống khẳng định điều này”.
8. Thời gian và phiên bản
Một chủ thể có thể chuyển nhượng quyền; hạn chế có thể thay đổi; hồ sơ có thể được đính chính. Nếu hệ thống chỉ giữ trạng thái hiện tại thì không thể tái dựng lịch sử. Vì vậy RRR, source và các đối tượng liên quan cần được quản lý theo hiệu lực và phiên bản.
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 |
Thiết kế tối thiểu có thể gồm PARTY, RRR, BAUNIT, SPATIAL_UNIT, SOURCE và các bảng liên kết. Tuy nhiên không nên sao chép tên lớp LADM thành schema vật lý ngay. Trước tiên phải map luật và nghiệp vụ địa phương: loại chủ thể, loại quyền, tỷ lệ sở hữu, thời hạn, trạng thái và nguồn. Sau đó mới chọn cấu trúc CSDL.
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: một thửa có ba người đồng quyền với tỷ lệ khác nhau; một ngân hàng có quyền bảo đảm; đồng thời thửa nằm trong hành lang hạn chế xây dựng. Nếu bảng PARCEL chỉ có owner_id và mortgage_flag, mô hình không thể biểu diễn đủ. Hãy thiết kế Party–RRR–SpatialUnit và chỉ ra record nào thay đổi khi một người chuyển phần quyền cho người khác.
| 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ập danh sách 8 loại chủ thể và 10 loại quan hệ quyền/hạn chế/trách nhiệm trong một use case.
- Vẽ conceptual model Party–RRR–SpatialUnit–Source.
- Thử tình huống đồng sở hữu và thế chấp.
- Kiểm tra có tái dựng lịch sử sau chuyển quyền không.
Những sai lầm cần tránh
- Gắn owner_id trực tiếp và coi đó là toàn bộ quan hệ pháp lý.
- Lặp thông tin Party trong từng quyền.
- Không lưu tỷ lệ/phạm vi/thời gian của RRR.
- Không liên kết quyền với nguồn chứng minh.
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 gắn trực tiếp một cột 'chủ sở hữu' vào tài sản nếu hệ thống phải quản lý đồng sở hữu, lịch sử và nhiều loại quyền.
- Chủ thể là con người/tổ chức; quyền, hạn chế, trách nhiệm là quan hệ pháp lý; đơn vị không gian là đối tượng được áp dụng.
- Một quyền có thể có nhiều chủ thể và một chủ thể có thể có nhiều quyền.
- Lịch sử hiệu lực phải được tách khỏi lịch sử ghi nhận trong hệ thống.
- LADM là mô hình khái niệm tham chiếu; khi triển khai phải lập hồ sơ quốc gia/địa phương phù hợp pháp luật.
Nguồn tham khảo
- ISO 19152-1:2024 – Land Administration Domain Model (LADM), Part 1: Generic conceptual model.
- ISO 19152-2:2025 – LADM, Part 2: Land registration.
- Bài giảng Hệ thống thông tin BĐS 2026–2027, Buổi 1–2 – Nguyễn Mạnh Hùng.
- Dale & McLaughlin – Land Information Management; nền tảng tư duy quản lý thông tin đất đai.
Bài tiếp theo: “Khách hàng – hợp đồng – giao dịch – tài sản liên kết với nhau thế nào?”.